Making the railway system work better for society.
Guide on the application of the common specifications of the register of Infrastructure
According to art 7 of Commission Implementing regulation (EU) 2019/777 of 16 May 2019 on the common specifications
for the register of railway infrastructure
|
Reference in ERA: |
ERA/GUI/RINF/MA |
|
Version in ERA: |
1.6.1 |
|
Date: |
24.02.2023 |
|
Document Type: |
Application Guide |
|
Document Status: |
public |
DOCUMENT INFORMATION
Table 1: Status of the document.
|
Version Date |
Author(s ) |
Section Number |
Modification Description |
|
Guide version 1.0 16/12/2014 |
ERA-IU |
all |
First publication This version is the basis of the iteration 2 of release 1.1 Modifications since 28/082014 are on the word version in track changes |
|
Guide Version 1.1 11/06/2015 |
ERA-IU |
|
This version is the basis of the iteration 2 of release 1.1. available on ERA website since June 2015 Introduction of a new OP type (private siding), of a Set attribute. Introduction of a Set attribute to manage link between some parameters. The changes underlined in blue were accepted in the RINF joint group meeting of April 2015.and apply in the RINF CUI available for test in ERA environment and “production” from ERA website. The changes underlined in green were accepted in the RINF joint group meeting of April 2015. The dates of application are indicated in corresponding footnotes. The file with track changes since 16/12/2014 presenting the differences with version 1.0 is available on ERA extranet. |
|
Guide Version 1.2 7/04/2016 |
ERA-IU |
|
This version is the basis of the iteration 2 of release 1.1.1 available on ERA website since end of March 2016. Cleaning up of previous modifications left visible. Deletion or Update of some parameters format. The list of modifications to the previous version of the guide is available in 4.4 “List of amendments”. |
|
Guide Version 1.2.1 19/01/2017 |
ERA-IU |
|
This version of the guide corresponds to the RINF currently available (RINF CUI File version 1.3) Correction of Inconsistences with the CUI in production Cleaning up when relevant Modification of format of parameter 1.1.1.3.7.11 “SOL Track Parameter CTD_MinAxleLoad” Update using the new format The list of modifications to the previous version of the guide is available in 4.4 “List of amendments”. |
|
Guide Version 1.2.2 20/06/2018 |
ERA-IU |
|
This version of the guide corresponds to the RINF currently available (RINF CUI File version 1.3.4) The list of modifications to the previous version of the guide is available in 4.4 “List of amendments”. |
|
Draft Guide Version 1.4 19/03/2019 |
ERA AAM |
|
Update according draft new RINF regulation (19/03/2019) To support the feedback of users before official publication |
|
Draft Guide Version 1.4.2 04/04/2019 |
ERA AAM |
|
Update according to comments received on Draft Guide Version 1.42 (04/04/2019) (listed in 5.6 / table 9) |
Table 1: Status of the document.
|
Version Date |
Author(s ) |
Section Number |
Modification Description |
|
Draft Guide Version 1.4.3 21/06/2019 |
ERA AAM |
|
Update according to comments received on previous Draft Guide Versions (listed in 5.6 / table 9) |
|
Guide Version 1.5 29/07/2019 |
ERA AAM |
|
Update, main modifications listed in 5.7List of amendments to Guide Version 1.4.3 (table 10) |
|
Guide Version 1.6 |
ERA AAM |
|
Update |
|
Guide Version 1.5.2.1 17/02/2020 |
ERA AAM |
|
Modifications listed in 5.8, Table 12. |
|
Guide Version 1.5.2.2 30/06/2020 |
ERA AAM |
|
Modifications listed in 5.8, Table 13. |
|
Guide Version 1.5.2.3 15/10/2020 |
ERA AAM |
|
Modifications listed in 5.8, Table 14. |
|
Guide Version 1.5.2.4 30/03/2021 |
ERA EXO |
|
Modifications listed in 5.8, Table 15. |
|
Guide Version 1.5.2.5 17/06/2021 |
ERA EXO |
|
Modifications listed in 5.8, Table 16. |
|
Guide Version 1.5.2.6 25/10/2021 |
ERA EXO |
|
Modifications listed in 5.8, Table 17. |
|
Guide Version 1.6.0 17/06/2022 |
ERA EXO |
|
Update, modifications listed in 5.9, Table 18. |
|
Guide Version 1.6.1 24/02/2023 |
ERA EXO |
|
Modifications listed in 5.9, Table 19. |
Fig. 1 – Levels of description of the network (adapted from UIC RailTopoModel Railway Network
Fig. 2 – International macro railway network with SoL lengths (D. KES) 23
Fig. 3 – Section of Line (SoL) between two Operational Points (OP) (provided by D. KES) 24
Table 1: Status of the document. 2
Table 2: Reference documents 7
Table 4a: Abbreviations and acronyms 15
Table 5: Characteristics of RINF parameters 50
Table 6 : List of border points 190
Table 7: List of domestic border points 205
Table 8: list of amendment to the previous version 206
Table 9: list of admendment to Draft Guide Version 1.4 212
Table 10: list of amendments to Draft Guide Version 1.4.3 215
Table 11: list of amendments to Draft Guide Version 1.5 Error! Bookmark not defined.
Table 12: list of amendments to Draft Guide Version 1.5.2.1.......................... Error! Bookmark not defined.7
Table 13: list of amendments to Draft Guide Version 1.5.2.2.......................... Error! Bookmark not defined.7
Table 14: list of amendments to Draft Guide Version 1.5.2.3.......................... Error! Bookmark not defined.7
Table 15: list of amendments to Draft Guide Version 1.5.2.4.......................... Error! Bookmark not defined.8
Table 16: list of amendments to Draft Guide Version 1.5.2.5.......................... Error! Bookmark not defined.9
Table 17: list of amendments to Draft Guide Version 1.5.2.6.......................... Error! Bookmark not defined.9
Table 18: list of amendments to Draft Guide Version 1.6.0............................. Error! Bookmark not defined.9 Table 19: list of amendments to Draft Guide Version 1.6.1 219
SCOPE OF THIS GUIDE
This document provides information on the application of the common specifications for the register of railway infrastructure as referred to in Article 49 of Directive (EU) 2016/797 of the Parliament and of the Council on the interoperability of the rail system within the European Union (RINF) therefore referred to as the Interoperability Directive.
This document does not introduce any new legally binding advice. It serves as a clarification tool for legal documents issued for RINF without however dictating in any manner compulsory procedures to be followed and without establishing any legally binding practice.
The guide has been prepared by the European Union Agency for Railways (ERA) with the support of railway sector organisations and National Safety Authority experts.
The guide is publicly available and it will be regularly updated to reflect progress related to system evolution and to changes of the TSIs and European standards. The reader should refer to the website of the ERA for information about its latest available edition.
This Guide is the basic document for all participants of the process of building RINF in European scale: for National Registration Entities (NREs) to build registers and collect data of their respective member states’ (MS) network.
The guide delivers the extended definitions of all the objects and parameters of the RINF. It provides guidance on the most common situations and solutions advised for modelling the railway network.
Examples and variety of possible solutions should support and unify constructions of registers of different MS of the EU.
This guide also delivers wide description of parameters, including their format, utility and explanation.
The instructions for use of the RINF via access to RINF application will be published as deliverable of RINF application – they are not included in this guide.
|
Table 2: Reference documents |
||||
|
Ref. Document Reference |
Official Journal |
Last Modification |
Version/ Comment |
Acronym |
|
[1] Commission implementing Decision 2011/633/EU of 15 September 2011 on the common specifications of the register of railway infrastructure |
L 256, 1.10.2011 |
15.09.2011 |
repealed |
|
|
[2] Commission implementing Regulation (EU) 2019/773 of 16 May 2019 on the technical specification for interoperability relating to the operation and traffic management subsystem of the rail system within the European Union and repealing Decision 2012/757/EU |
LI 139/5 |
27.5.2019 |
|
OPE TSI |
|
[3] Directive (EU) 2016/798 of the European Parliament and of the Council of 11 May 2016 on railway safety (recast) |
L 138/102 |
26.5.2016 |
|
|
|
[4] Directive 2016/797 of the European Parliament and of the Council of 11 May 2016 on the interoperability of the rail system within the European Union (recast) |
L 138/44 26.5.2016 |
|
|
|
|
[5] Commission implementing Regulation (EU) 2019/776 of 16 May 2019 amending Commission Regulations (EU) No 321/2013, (EU) No 1299/2014, (EU) No 1301/2014, (EU) No 1302/2014, (EU) No 1303/2014 and (EU) 2016/919;Commission implementing Regulation (EU) 2020/387 of 9 March 2020 amending Regulations (EU) No 321/2013, (EU) No 1302/2014 and (EU) 2016/919 as regards the extension of the area of use and transition phases Commission Implementing Decision 2011/665/EU as regards the alignment with Directive (EU) 2016/797 of the European Parliament and of the Council and the implementation of specific objectives set out in Commission Delegated Decision (EU) 2017/1474 |
L 139I/108, 27.05.2019 L 73/6 |
27/05/2019 10/03/2020x |
|
CCS TSI |
|
Table 2: Reference documents |
||||
|
Ref. Document Reference |
Official Journal |
Last Modification |
Version/ Comment |
Acronym |
|
[6] Regulation (EU) No 913/2010 of the European Parliament and the Council of 22 September 2010 concerning a European rail network for competitive freight. |
OJ L 276, 20.10.2010 |
11.12.2013 |
|
|
|
[7] Document ‘Interfaces between CCS track-side and other subsystems’ referenced as Index 77 in the list of mandatory specifications (Annex A) of the revised CCS TSI for HS and CR adopted by a Commission Implementing Decision (EU) 2019/776 |
27/05/2019 |
20/09/2018 |
ERA/ERTMS/ 033281 V4.0 |
|
|
[8] List of CSS Class B systems |
27/05/2019 |
11/06/2019 |
ERA_TD_201 1-11 |
|
|
[9] Decision 2008/232/EC TSI relating to the Rolling Stock subsystem of the trans-European HS rail system |
L 84, 26.03.2008 |
23.07.2012 |
Commission Decisions 2008/232/EC and 2011/291/EU are repealed |
HS RS TSI |
|
[10] Decision 2011/229/EU TSI “Rolling stock – noise” |
L 99, 13.02.2011 |
23.07.2012 |
repealed |
|
|
[11] Commission Regulation (EU) No. 321/2013 of March 2013 TSI Freight Wagons |
L 104, 12.04.2013 |
|
Draft Regulation amending Regulation (EU) No 321/2013 was approved by RISC in October 2014 |
WAG TSI |
|
[12] Decision 2011/275/EU TSI relating to the infrastructure subsystem of the trans-European conventional rail system |
14.05.2011 |
|
Decisions 2008/217/EC and 2011/275/EU are repealed |
CR INF TSI |
|
Table 2: Reference documents |
||||
|
Ref. Document Reference |
Official Journal |
Last Modification |
Version/ Comment |
Acronym |
|
|
|
|
with effect from 1 January 2015. |
|
|
[13] Decision 2008/217/EC TSI relating to the Infrastructure subsystem of the trans-European HS rail system |
L 77, 19.03.2008 |
|
Decisions 2008/217/EC and 2011/275/EU are repealed with effect from 1 January 2015. |
HS INF TSI |
|
[14] Regulation 62/2006/EC TSI “Telematics Applications for Freight” |
L 13, 18.01.2006 |
Regulation 280/2013 22.03.2013 |
repealed |
|
|
[15] Strategic European deployment plan for the European-wide implementation of the TSI Telematics Applications for Freight (TAF TSI) |
NA |
published 16/02/2010 |
Version 1.0 |
|
|
[16] Decision 2011/291/EU TSI LOC&PAS of the trans- European conventional rail system |
L139, 26.05.2011 |
23.07.2012 |
Commission Decisions 2008/232/EC and 2011/291/EU are repealed |
CR LOC§PAS TSI |
|
[17] Decision 2008/284/EC TSI Energy trans- European HS rail system |
L 104, 14.04.2008 |
Decision 2012/464/EU |
Decisions 2008/284/EC and 2011/274/EU are repealed with effect from 1 January 2015. |
HS ENE TSI |
|
[18] Commission Regulation (EU) No 454/2011 of 5 May 2011 on the technical specification for interoperability relating to the subsystem |
L 123, 12.05.2011 |
L 194, 21.07.2012 |
|
TAP TSI |
|
Table 2: Reference documents |
||||
|
Ref. Document Reference |
Official Journal |
Last Modification |
Version/ Comment |
Acronym |
|
‘telematics applications for passenger services’ of the trans-European rail system. |
|
|
|
|
|
[19] Decision 2008/163/EC TSI SRT trans-European HS and conv. rail system |
L 64, 07.03.2008 |
|
Repealed with effect from 1 January 2015. |
|
|
[20] Decision 2008/164/EC TSI PRM trans-European HS and conv. rail system |
L 64, 07.03.2008 |
|
|
PRM TSI |
|
[21] Framework Mandate to the European Railway Agency for the Performance of Certain Activities under Directives 96/48/EC and 2001/16/EC |
|
|
|
|
|
[22] Commission Recommendation 2014/881/EU of 18 November 2014 on the procedure for demonstrating the level of compliance of existing railway lines with the basic parameters of the technical specifications for interoperability |
L 356 12.12.2014 |
|
|
|
|
[23] ERA Document about practical arrangements for transmitting interoperability document (ERA/INF/10-2009/INT) |
NA |
27.08.2009 |
Version 0.1 |
|
|
[24] Regulation (EU) No 1315/2013 of the European Parliament and of the Council of 11 December 2013 on Union guidelines for the development of the trans-European transport network and repealing Decision No 661/2010/EU |
L 348/1, 20.12.2013 |
|
|
|
|
[25] RINF XML Data Validation Guide |
|
|
ERA Document |
|
|
[26] Commission Implementing Decision 2014/880/EU of 26 November 2014 on the common specifications of the register of railway infrastructure and repealing Implementing Decision 2011/633/EU |
L 356 12.12.2014 |
|
|
RINF Decision |
|
Table 2: Reference documents |
||||
|
Ref. Document Reference |
Official Journal |
Last Modification |
Version/ Comment |
Acronym |
|
[27] Commission Regulation (EU) No 1299/2014 of 18 November 2014 on the technical specifications for interoperability relating to the ‘infrastructure’ subsystem of the rail system in the European Union |
L 356 12.12.2014 |
|
|
INF TSI |
|
[28] Commission Regulation (EU) No 1301/2014 of 18 November 2014 on the technical specifications for interoperability relating to the ‘energy’ subsystem of the rail system in the Union |
L 356 12.12.2014 |
|
|
ENE TSI |
|
[29] Commission Regulation (EU) No 1300/2014 of 18 November 2014 on the technical specifications for interoperability relating to accessibility of the Union's rail system for persons with disabilities and persons with reduced mobility |
L 356 12.12.2014 |
|
|
PRM TSI |
|
[30] Commission Regulation (EU) No 1302/2014 of 18 November 2014 concerning a technical specification for interoperability relating to the ‘rolling stock — locomotives and passenger rolling stock’ subsystem of the rail system in the European Union |
L 356 12.12.2014 |
|
|
LOC§PAS TSI |
|
[31] Commission Regulation (EU) No 1303/2014 of 18 November 2014 concerning the technical specification for interoperability relating to ‘safety in railway tunnels’ of the rail system of the European Union |
L 356 12.12.2014 |
|
|
SRT TSI |
|
[32] Draft Commission Decision amending Commission Decision 2012/88/EU on the technical specification for interoperability relating to the control-command and signalling subsystems of the trans-European rail system |
|
|
pending publication |
|
|
[33] Commission Regulation (EU) No 1305/2014 of 11 December 2014 on the technical specification for interoperability relating to the telematics applications for freight subsystem of the rail |
L 356 12.12.2014 |
|
|
TSI TAF |
|
Table 2: Reference documents |
||||
|
Ref. Document Reference |
Official Journal |
Last Modification |
Version/ Comment |
Acronym |
|
system in the European Union and repealing the Regulation (EC) No 62/2006 |
|
|
|
|
|
[34] Directive 2012/34/EU of the European Parliament and of the Council of 21 November 2014 establishing a single European railway area |
L 343/32, 14.12.2012 |
|
|
|
|
[35] Regulation n° 1304/2014 of 26 November 2014 on the technical specification for interoperability relating to the subsystem ‘rolling stock — noise’ amending Decision 2008/232/EC and repealing Decision 2011/229/EU amended by Commission Regulation (EU) 2019/774 of 16 May 2019 |
L 356 12.12.2014 |
|
|
TSI NOI |
|
[36] COMMISSION IMPLEMENTING REGULATION (EU) 2019/777 of 16 May 2019 on the common specifications for the register of railway infrastructure and repealing Implementing Decision 2014/880/EU |
LI 139/312 27.5.2019 |
|
|
RINF REG |
Specific definitions
This section provides general definitions. The following table provides a list of terms used in this guide and their definitions. Mainly these terms have been already defined in the relevant legal documents; in these cases the source of the definition is indicated.
|
Table 3: Definitions |
|
|
Term |
Definition/ Source |
|
Acts issued by the Agency |
According to Article 2(a) of Regulation 881/2004/EC and its following amendment, the Agency is entitled to address recommendations to the Commission, concerning issues related to safety, interoperability, national rules classification, maintenance of vehicles, staff qualification and public registers. Furthermore, Article 2(b) of the same Regulation allows the Agency to issue also technical opinions to the Commission- following its request- relating to national rules, quality of the work of Notified Bodies and any project implying modifications in the Interoperability community rail system and involving EU funds |
|
Basic parameter |
Any regulatory, technical or operational condition which is critical to interoperability and is specified in the relevant TSIs. (Article 2 (k) of Directive 2008/57/EC) |
|
Conformity |
According to Article R1 (12), Annex 1 of Decision 768/2008/EC it corresponds to the fulfilment of specified requirements by a product, process, service, system, person or body. |
|
Conformity assessment |
...the process demonstrating whether specified requirements relating to a product, process, service, system, person or body have been fulfilled. (Article R1(12), Annex 1 of Decision 768/2008/EC) |
|
Existing rail system |
...the structure composed of lines and fixed installations of the existing, rail system plus the vehicles of all categories and origin travelling on that infrastructure. (Article 2 (o) of Directive 2008/57/EC) |
|
Harmonised standard |
[It] “means any European standard adopted by one of the European standardisation bodies listed in Annex I to Directive 98/34/EC of the European Parliament and of the Council of 22 June 1998 laying down a procedure for the provision of information in the field of technical standards and regulations and of the rules on Information Society services in connection with a mandate by the Commission drawn up in accordance with the procedure referred to in Article 6(3) of that Directive, which, by itself or together with other standards, provides a solution as regards compliance with a legal provision. (Article 2 (u) of Directive 2008/57/EC) |
|
Infrastructure Manager |
...any body or undertaking that is responsible in particular for establishing and maintaining railway infrastructure, or part thereof, as defined in article 3 of Directive 91/440/EEC, which may also include the management of infrastructure control and safety systems. The functions of the infrastructure manager on a network or part of a network may be allocated to different bodies or undertakings. (Article 3 (b) of Directive 2004/49/EC) |
|
Table 3: Definitions |
|
|
Term |
Definition/ Source |
|
National Registration Entity |
Entity in charge of setting up and maintaining its own register. Nominated by each Member State |
|
National Safety Authority |
National body entrusted with the tasks regarding railway safety in accordance with Directive 2004/49/EC. (Article 3(g) of Directive 2004/49/EC) |
|
Notified body |
...the bod[y] which [is] responsible for assessing the conformity or suitability for use of the interoperability constituents or for appraising the “EC” procedure for verification of the subsystems. (Article 2 (j) of Directive 2008/57/EC) |
|
Open point |
According to Article 5(6) of Directive 2008/57/EC, when “...certain technical aspects corresponding to the essential requirements cannot be explicitly covered in a TSI, they shall be clearly identified in an annex to the TSI as open points...” |
|
Placing in service |
...all the operations by which a subsystem or a vehicle is put into its design operating state. (Article 2 (q) of Directive 2008/57/EC) |
|
Railway Undertaking |
...any public or private undertaking, the activity of which is to provide transport of goods and/or passengers by rail on the basis that the undertaking must ensure traction; this also includes undertakings which provide traction only. (Article 3 (c) of Directive 2004/49/EC) |
|
Register of Infrastructure (RINF) |
The Register of Infrastructure referred to in Article 35 of Directive 2008/57/EC indicates the main features of fixed installations, covered by the subsystems: infrastructure, energy and parts of control-command and signalling. It publishes performance and technical characteristics mainly related to interfaces with rolling stock and operation. |
|
Specific case |
...any part of the rail system which needs special provisions in the TSIs, either temporary or definitive, because of geographical, topographical or urban environment constraints or those affecting compatibility with the existing system. This may include, in particular, railway lines and networks isolated from the rest of the Community, the loading gauge, the track gauge or space between the tracks and vehicles strictly intended for local, regional or historical use, as well as vehicles originating from or destined for third countries. (Article 2 (l) of Directive 2008/57/EC) |
Abbreviations and acronyms
Table 4a: Abbreviations and acronyms
|
ABBREVIATION / ACRONYMS |
FULL TEXT |
|
AC |
Alternating Current |
|
ADD |
Automatic Dropping Device |
|
CCS |
Command Control and Signaling |
|
CEN |
European Committee for Standardisation (Comité Européen de Normalisation |
|
CENELEC |
European Committee for ELECtrotechnical Standardisation (Comité Européen de Normalisation ELECtrotechnique) |
|
CR |
Conventional Rail |
|
CUI |
Common User Interface |
|
DC |
Direct Current |
|
DeBo |
Designated Body |
|
EC |
European Commission |
|
EDOR |
ERTMS Data Only Radio (modem) |
|
EEA |
European Economic Area |
|
EEC |
European Economic Community |
|
EIRENE |
European Integrated Radio Enhanced NEtwork |
|
EN |
European standard |
|
ENE |
Energy |
|
ERA |
European Railway Agency also called “the Agency” |
|
ERADIS |
European Railway Agency Database of Interoperability and Safety |
|
ERATV |
European Register of Authorised Types of Vehicles |
|
ERTMS |
European Rail Traffic Management System |
|
ETCS |
European Train Control System |
|
ETS |
European Telecommunications Standard |
|
EU |
European Union |
|
FRS |
Functional Requirements Specification of ERTMS |
|
GPRS |
General Package Radio Service |
|
GPS |
Global Positioning System |
|
GSM-R |
Global System for Mobile communications- Railway |
|
GUI |
Graphical User Interface |
|
HS |
High Speed |
|
IC |
Interoperability Constituent |
|
IM |
Infrastructure Manager |
|
INF |
Infrastructure |
|
ISO |
International Organisation for Standardisation |
|
IU |
Interoperability Unit of ERA |
|
LP |
Location Point |
|
MS |
EU or EEA Member State |
|
NAP |
Normaal Amsterdams Peil |
|
NID_XUSER |
Identity of User Design Authority |
|
NoBo |
Notified Body |
|
NB-Rail |
Coordination group of Notified Bodies |
Table 4a: Abbreviations and acronyms
|
ABBREVIATION / ACRONYMS |
FULL TEXT |
|
NRE |
National Registration Entity |
|
NSA |
National Safety Authority |
|
NYA |
Not Yet Available |
|
OC |
Organisation Code |
|
OCL |
Overhead Contact Lines |
|
OP |
Operational Point |
|
PRM |
Persons with Reduced Mobility |
|
PLC |
Primary Location Code |
|
RA |
Route Availability |
|
RBC |
Radio Block Center |
|
REC |
Railway Emergency Call |
|
RFC |
Railway Freight Corridor |
|
RINF |
Register of Infrastructure |
|
RST |
Rolling Stock |
|
RU |
Railway Undertaking |
|
SEDP |
Strategic European Deployment Plan (TAF TSI) |
|
SoL |
Section of Line |
|
SRS |
System Requirements Specifications of ERTMS |
|
SRT |
Safety in Railway Tunnels |
|
TAF |
Telematic Application for freight |
|
TAP |
Telematic Application for passengers |
|
TEN-T |
Trans-European Transport Network |
|
TSI |
Technical Specifications for Interoperability |
|
UIC |
International Union of Railways (Union Internationale des Chemins de fer) |
|
WG |
Working Group |
|
WP |
Working Party |
|
XML |
Extensible Markup Language |
|
XSD |
XML Schema Definition |
Table 4b: Abbreviations and acronyms used in XML tags
|
ABBREVIATION / ACRONYMS |
FULL TEXT |
|
CBP |
Control-Command Brake Parameters |
|
CCD |
Control-Command Complaint Detection |
|
CDE |
Control-Command Declaration |
|
CEI |
Control-Command Electromagnetic Interferences |
|
CLD |
Control-Command Line-Side Degraded |
|
COP |
Control-Command Other Parameters |
|
CPE |
Control-Command Protection ETCS |
|
CPO |
Control-Command Protection Other |
|
CRG |
Control-Command Radio GSMR |
|
ABBREVIATION / ACRONYMS |
FULL TEXT |
|
CRS |
Control-Command Radio System Other |
|
CTD |
Control-Command Train Detection |
|
CTS |
Control-Command Transition System |
|
ECS |
Energy Contact System |
|
EDE |
Energy Declaration |
|
EOS |
Energy OCL Separation |
|
EPA |
Energy Pantograph |
|
IDE |
Infrastructure Declaration |
|
HIS |
Infrastructure Health and Safety |
|
ILL |
Infrastructure Line Layout |
|
ILR |
Infrastructure Load Resistance |
|
IPL |
Infrastructure Platform |
|
IPP |
Infrastructure Performance Parameters |
|
ISC |
Infrastructure Switches and Crossings |
|
ITP |
Infrastructure Track Parameters |
|
ITS |
Infrastructure Train Servicing |
|
ITU |
Infrastructure Tunnel |
CLARIFICATIONS ON THE RINF
The implementation of the register of infrastructure requires:
A common knowledge and understanding of the concepts to be used for the description of each concerned network,
A shared set of parameters related to all the fundamental features of the railway networks. The specification of parameters allows them to be made available through the RINF application.
It can be carried out by successive steps depending on the strategy adopted by each Member State that has to be notified to the Commission. In addition, by providing its data in stages, each infrastructure manager (IM) can increase the content and the level of description of a given network. After each update of data describing its network by a NRE, the RINF application publishes the complete set of data received from MS. Partial updates are not possible. Whenever a Member State wants to update / improve the description of its network, it must upload to the RINF application a complete set of data which will replace the previous one.
Geographical scope
The geographical scope for RINF corresponds to the scope of the Interoperability directive (Directive (EU) 2016/797) as implemented by each Member State.
In this context, Member States may have excluded “privately owned railway infrastructure, including sidings, used by its owner or by an operator for the purpose of their respective freight activities or for the transport of persons for non-commercial purposes, and vehicles used exclusively on such infrastructure; (art 1.4.a). See annex 1 of the IOD
The technical scope
RINF ‘specifications concern data about the following structural subsystems of the Union rail system:
the infrastructure subsystem,
the energy subsystem,
the trackside control-command and signalling subsystem.
Purpose
The type of data describing the infrastructure is the functional purpose of the RINF as defined in art 2.2 of the Annex of the RINF Regulation.
The value of the parameters to be used to check the technical compatibility between vehicle and route are corresponding to “design” values. These values need to be up to date to allow a RU to:
Develop technical specifications for vehicle design; for new vehicles;
Identifying the vehicles compatible with the planned route/path and its operational conditions;
Provide relevant data to identify infrastructure characteristics of the intended area of use and facilitate the design of rolling stock and the feasibility check of train services.
The type of data intended to facilitate the verification of the technical compatibility between a fixed subsystem and the network into which it is incorporated and to monitor the progress of interoperability of railway fixed installations.
These values need to be up to date to allow a RU to plan the train composition and to perform the route compatibility check on the attributed route/path in the weeks before starting the service operation.
The main features supporting the RINF model are described in the RINF regulation [36]. Their definitions are reproduced below:
An ‘operational point’ (OP) means any location for train service operations, where train services may begin and end or change route, and where passenger or freight services may be provided; ‘operational point’ means also any location at boundaries between Member States or infrastructure managers;
‘Section of line’ (SoL) means the part of line between adjacent operational points and may
consist of several tracks;
‘Running track’ means any track used for train service movements; passing loops and meeting loops on plain line or track connections only required for train operation are not published;
‘Siding’ means any track within an operational point, which is not used for operational
routing of a train.
‘Location point’ (LP) is a specific point on a track of a SoL (not permitted for OP) where value of a parameter changes. The use of LP is non mandatory.
Levels of the network description
The railway network is presented for RINF purpose as a number of operational points (OPs) connected with sections of line (SoLs). A line can be described in different levels of details. Fig. 1 below shows several ways of representation from a detailed to a simple one. A National Registration Entity can choose what level to populate from simple to detailed level. The visual tool of the RINF application only presents OPs and SoLs of a line updated by an NRE. There is no link, except the number of OP and SoL, between the initial description of a line by NRE and the final representation allowed by RINF application where the successive levels of zoom are organised according to categories of lines and do not provide supplementary details regarding the description of a lines and its elements.
Within OP there are two types of tracks: running tracks and sidings (see explanations about differences in the following sections).
Installations located along the tracks are attached to the tracks. Parameters related to subsystems INF, ENE, CCS within a SoL or related to subsystem INF within an OP are provided for each “track” element of the SoL or OP (“running track” and/or “siding”). Data provided for each parameter are valid for the whole element described:
- from the start OP to the end OP of a SoL for a “running track”; except if “location point” is used;
- inside the OP for a “siding”.
Fig. 1 – Levels of description of the network (adapted from UIC RailTopoModel Railway Network Description)
The Operational Point
Operational Point is understood as a point without dimensions, attributed with generic parameters and with objects described by their own parameters. OP is the primary element of the network and selection of OPs is the first task for IMs in procedure of presenting its network. The OP is independent from the notion of line. An OP is not described by belonging to one or several lines. Only SoLs are linked to lines.
An OP will be presented by so called ‘centre point’ on a global map. This centre point is defined
by relevant IM (note that it is not always in the centre of the OP area) and determines the
geographical coordinates (and the kilometre from the start of the railway line) of OP to be inserted to generic data about location of the OP.
An OP is allowed to have no track (e.g., border points, technical change or OP private siding). For the purpose of the RINF, the following types of OPs have been defined:
Station – big or huge station with several functions, important for international traffic, basic for national railway system;
Small station – multifunctional station not so big and not so important like “Station”;
Passenger terminal – station with dominating function of service for passenger traffic;
Freight terminal – station dominantly serving for loading and unloading of freight trains;
Depot or workshop – group of tracks used by depot or workshop for RST maintenance;
Train technical services – group of tracks for servicing trains (parking, washing, etc.);
Passenger stop – small OP consisting of at least one platform, normally serving mostly for local passenger services;
Junction – OP consisting of at least one turnout, normally used mostly for changing direction of trains, with reduced or not existing other functions;
Border point – located in the point where a border between MSs meets a railway line;
Shunting yard – group of tracks used for shunting trains, mostly related to freight traffic;
Technical change - to describe a change on CCS or a type of contact line or a Gauge changeover facility – fixed installation allowing a train to travel across a break of gauge where two railway networks with different track gauges meet;
Switch - OP consisting of only one switch. It describes a single switch without any extension contrary to a junction that has a real spatial extension and is generally delimited by entry signals;
Private siding - OP that describes the embranchment located on the main line that leads to the private siding with the information regarding the embranchment characteristics;
Domestic border point – located exactly in the point where a border between IMs meets a railway line.
Principles:
- For the implementation of the RINF Decision, RINF was populated on the principles
below:
There is no obligation to include in RINF all currently existing traffic points of the network.
There are no detailed rules for selecting OPs for RINF. An OP must be defined on a network each time a choice in matter of route can be made.
Only points or stations which are important for the traffic, stopping and starting trains, or delivering services related to trains and their clients must be identified as OP.
It is permissible to ignore some intermediate stops located on the SoL if they are not important from an operational or technical point of view.
- For the implementation of the RINF Regulation and the needs of the IV Railway Package, RINF should display every point allowing to describe a route corresponding to a service operated by a RU. Moreover, as defined by RINF Regulation “ ‘operational point’(OP) means any location for train service operations, where train services may begin and end or change route and where passenger or freight services may be provided; it includes locations at boundaries between Member States or infrastructure managers;”.
In parallel, the implementation of the TAF/TAP TSIs has promoted the definition of Primary Location Codes (PLC) whose ID is a parameter of the OP.
As a conclusion,
Regarding OP type n°11 (“Technical change”)
Changes of value of parameters may require defining an OP (type n°11). It allows in particular to describe the implementation of ETCS using parameter 1.1.1.3.2. It allows also to describe a Gauge changeover facility – fixed installation. At last, “type 11” OP allows finally to describe a technical change in energy subsystem, but this solution should be used as little as possible. It should be noted that:
the RINF already allows describing several types of contact line systems and several energy power systems on a given element of a SoL by repeating the data;
the use of the Location points makes possible to precise specific points where technical changes are made.
Regarding OP type n° 9 (“Border point”)
For these OP between two MS, bilateral agreements have to be achieved concerning name, location of them and other attributes to be included in the registers. The list of borders points is agreed between NREs and managed by the Agency. The list is in 5.2.
Regarding OP type n° 14 (“Domestic border point”)
Located exactly in the point where a border between IMs meets a railway line. Their OP ID and other attributes is managed by each NRE and published by the Agency in 5.2. This list will become necessary when IMs will be allowed to directly import their data in the RINF application.
It is necessary to use the correct OP ID to ensure the continuity of the network.
Specific problems may be met in case of large stations or nodes. Then IM may divide such station into several OPs with different types.
It could be useful to take in account of the existence of “PrimaryLocation Codes” already defined
for the use of the TAP/TAF TSIs before defining OP for the RINF needs.
It is mandatory to select OP “Border point”. For these OP between two MS, bilateral agreements have to be achieved concerning name, location of them and other attributes to be included in the registers. The list of borders points managed by the Agency and agreed between NREs is in 4.2.
Fig 2. Below provides an example of Border points between three MS.
7.8
A
12.8
X
Border OP
11.9
45.7
G
14.8
Border OP
43.7
O
MS 1
10.6
Y
17.7
MS 2
Border OP
Border OP
Border OP
44.1
19.2
MS 3
15.1
K
15.3
L
14.7
M
14.5
4.7
Z
B
C
13.1
13.3
border
9.7
23.6
12.3
E
F
N
22.7
45.9
= normal domestic operational point
= section of line
= section of line crossing a border
Fig. 2 – International macro railway network with SoL lengths (D. KES)
The same type of agreements will have to be achieved at national level in order to determinate the border points between several IMs and to be able to merge several datasets in a single national one. This task shall be carried out at national level by the NRE.
The Section of line
A section of line is the connection between two adjacent OPs. Section of Line is the second basic element of RINF.A line is a continuous chain of sections of lines and operational points when except beginning and end of a line, the OP at end of a SoL is the OP at start of consecutive SoL.
A single SoL may be settled to be a line at its own. As each SoL is described separately, number of tracks and values of related parameters may be different on different SoL of the same line.
It is important to underline that in one SoL may be included tracks only of the same line. When two different lines are running in parallel – passing by the same OPs - data on tracks of each line has to be published in two separate SoLs.
For proper presentation of the network and for avoiding uncertainties in routes and lines, data about OPs on the respective ends of SoLs must be entered carefully.
SoL which is a single track connecting two OPs within a big node (when this big node has been divided into several OPs) has a reduced set of parameters. Such track is indicated as ‘Link’ in parameter 1.1.0.0.0.6 ‘Nature of Section of Line’. Only the group 1.1.0.0.0 ‘Generic information’ must be completed.
OP A OP B
RINF Length SoL
||
||
OP-
demarcation points
1
2
center
3
4
|| BA
|| AB
OP-
demarcation points
||
||
OP-
demarcation points
1
2
center 3
4
||
||
OP-
demarcation points
Scope OP parameters
Scope SoL parameters
Scope OP parameters
Scope OP-track parameters Scope SoL-track parameters Scope OP-track parameters
Fig. 3 – Section of Line (SoL) between two Operational Points (OP) (provided by D. KES)
Elements of an operational point
Elements inside an OP are ‘Running tracks’ and ‘Sidings’. ‘Running tracks’ in OP are regarded all those tracks which are used for operation of trains in service movements. It means that not only main tracks of a station are ‘Running tracks’ according to RINF, but also all additional tracks where passenger trains stop at platforms or where freight trains over-pass group of tracks with platforms.
‘Siding’ is regarded as a single/simple track. Sidings are all those tracks where running trains in service movements ends and which are not used for operational routing of a train. According to RINF, ‘Siding’ is any track which “delivers support” for the traffic, but which is not a route for the traffic.
In an OP, only few parameters related to infrastructure subsystem are included. For the other parameters related to infrastructure subsystem energy and command control and signalling subsystems, it is assumed that, in an OP, the same parameter regarding CCS and ENE are corresponding to those of neighbouring SoLs (permitting at least to enter to the center of OP). The exception is the OP used for describing a technical change on type of contact line or CCS.
The specific for OP description is the group of parameters related to platforms. Platform for the purpose of RINF is understood as a platform edge. Platform identification shall concern only the part of the structure neighbouring to the track (interfaced with trains).
In case when normal platform numbering concerns the whole structure between two tracks, the ‘RINF platform’ may be labelled using the platform number and the track ID to which the specific edge belongs.
It is worth adding that platform is the installation for providing passengers’ access to trains – this is not the construction for loading or unloading freight trains.
It is very important for RINF to have a unique identification for each OP (OP ID). OP ID is the code composed from country code and alphanumeric OP code developed by MS or IM. We suggest using those number or abbreviations which are applied in route books or in documentation of the IM. In case of absence of such sources the coding system within the MS may be developed specially for RINF.
Finally, one or several “PLC” can exist in the OP area. The corresponding primary location codes shall be provided using the relevant parameter (1.2.0.0.0.3).
Some IMs could have chosen not to describe the siding itself but the location of it on its network where a switch leads to a private installation. The definition of the OP private siding was modified allowing to describe so.
As any siding, the following parameters have at least to be filled:
1.2 OPERATIONAL POINT
Generic information
OPName / Name of Operational point 1.2.0.0.0.2 UniqueOPID /Unique OP ID
1.2.0.0.0.3 OPTafTapCode / OP TAF TAP primary location code 1.2.0.0.0.4 OPType / Type of Operational Point
1.2.0.0.0.5 OPGeographicLocation / Geographical location of Operational Point 1.2.0.0.0.6 OPRailwayLocation / Railway location of Operational point
1.2.2 OPSiding / SIDING
Generic information
IM’s Code / IM’s Code
OPSidingIdentification / Identification of siding (INF)
IPP / Performance parameter 1.2.2.0.2.1 IPP_Length / Usable length of siding
Line layout
ILL_Gradient / Gradient for stabling tracks
ILL_MinRadHorzCurve / Minimum radius of horizontal curve
ILL_MinRadVertCurve / Minimum radius of vertical curve
Elements of a section of line
Section of Line consists of one or more tracks of a same national line starting from OP at start of this SoL and ending in the OP at the end of the same SoL.
Values of parameters displayed for a SoL are guaranteed along the corresponding track outside OPs and at least for one or more running tracks inside the area of the start OP and of the end OP up to their center point.
It is advised to organise introduction of data to registers in the way which permits placing the same value of a parameter into all tracks of the same SoL where this is valid.
With regard to the tunnel, the definition foreseen by new SRT TSI [31] is “A railway tunnel is an excavation or a construction around the track provided to allow the railway to pass for example higher land, buildings or water. The length of a tunnel is defined as the length of the fully enclosed section, measured at rail level. A tunnel in the context of this TSI is 0.1km or longer.”
‘Tunnel’ is understood in RINF as the special area of the track with special conditions. So, parameters concerning a tunnel are the attributes of a track; however, those parameters are given in group of parameters titled ‘Tunnel’. If there are several tracks in the same tunnel, data related to this tunnel will be repeated in description of each track. On the other hand, if a track passes through several tunnels, in the description of the track will be mentioned several groups of parameters titled ‘Tunnel’ to describe each of the tunnel separately. The similar rules concern tunnels in OPs which may contain both tracks and sidings.
The Location Point
IMs have the possibility to introduce within SoL Location Points to describe specific change in the value of a parameter at running track level (it cannot be used for parameters of SoL level). LP can be used each time several successive values of a parameter are described for a given track in a same SoL. The new value is valid from the specified location in the direction of the principal SoL direction of the traffic (defined by increasing kilometres, see description of parameter 1.1.0.0.0.3 in Table 5).
The following data has to be included in the description of the LP:
Km [NNN.NNN] of the line of the point from where the new value is valid
Geographical longitude of the point from where the new value is valid
Geographical latitude of the point from where the new value is valid
The new value of the parameter. An example of xml is below:
-<SOLTrackParameter Value="351" IsApplicable="Y" ID="IPP_MaxSpeed">
<LocationPoint Value="130" Latitude="14.1345" Longitude="-43.9600" Kilometer="12.45"/>
<LocationPoint Value="123" Latitude="14.1366" Longitude="43.9700" Kilometer="13.1"/>
</SOLTrackParameter>
The application of LP is optional. When LPs are not used, they will not appear in the XML file exported from a register to RINF application. Even if provided, they will only be displayed in the details of the running track and will not appear in the final representation of the network. The RINF application in its current development will not search in Location Point values.
But any search will display the location point(s) and the specific value each time it exists for a given SoL. The location point is described by its railway location, geographical coordinates and value of the parameter involved.
General information about parameters of RINF
Parameters collected in RINF are mainly:
Generic data – valid for SoL, OP, running track, siding,
Data related to specific subsystems – for INF, ENE and CCS in SoLs; only for INF in OP,
Data for performance parameters, for objects (tunnel, platform) or for providing references of certificates (declarations).
Organisation of parameters in RINF is presented in table 1 of the annex to the EC RINF Regulation.
It is important to underline that it is permitted/foreseen to repeat certain parameters or groups of parameters. For example: if there are several tracks on the Section of Line – then the whole set of parameters for Track has to be repeated for each track in the SoL.
Also, when several data relating to the same parameter co-exist, then this parameter may be repeated. For example, when there are several “EC intermediate statement of verification” (ISV) declarations for a single subsystem concerning the same track, then this parameter may be repeated so many times as many declarations concern this track.
But please be aware, not all parameters may be repeated – the respective information is provided
in a specific attribute “Can be repeated” with the value ‘Y’ (See table 5).
For the purpose of the RINF, the appropriate value of a parameter has to be the most critical from all values met along the whole track of the SoL.
That is why it is very important to make a thorough selection of OPs.
NREs/IMs can adopt an “in stages” approach starting to describe their network with the most restrictive characteristic.
Some values of some parameters may not exist – like ‘Tunnel identification’, ‘EC declaration of verification’, ‘OP TAF/TAP primary location code’. Then the applicability of that parameters will be “N”.
In case of multi-rail track, a set of data is to be published separately to each pair of rails to be operated as separate track (the whole set of parameters for the separate track has to be delivered – be careful then with the track identification).
In case of multiple ENE and/or CCS subsystems, the ability to repeat the relevant of parameters allows to describe these particularities of a running track.
The data uploaded to the RINF application should follow metric system principals. For example, in the UK miles or miles per hour will be transformed respectively to kilometres or kilometres per hour prior uploading to the RINF application. The exception are values of speed related to RA (Route Availability) given for Load Capability (1.1.1.1.2.4).
Objects for separate dating (future validity)
Date of validity of current data collected in RINF is the same as date of export from the MS’
registers of infrastructure to the RINF application.
The objects for which this future validity date may be applied are: Operational Point, Section of Line, Track, Siding, Tunnel and Platform. These dates are not described as attributes of parameters but have to be inserted in the RINF XML.
RINF parameters are listed in table 5. Each presentation of a parameter provides clarification on the requirements, data presentation, when relevant list of possible answers, information on applicability and mandatory status, ability to be repeated and the XML name of the parameter that will be used in the XML file for uploading RINF data in the RINF application.
The XML name of parameters was introduced to replace the numbering identification in order to allow further introduction of new parameters or to delete existing ones. It also provides a better readability of the XML file.
Table 5 is the basis of the validation process used by the RINF application. This process is described
in the “RINF XML Data Validation Guide” [25].
An optional attribute was also introduced in the XML for some parameters. It is described in 1.1 of RINF XML Data Validation Guide.
This element is the “optional value”. This optional attribute is used only for readability of the XML file. When several answers are proposed in table 5 for providing the value of a parameter, these values will be introduced encoded and supported by an “optional value” attribute where the value
itself of the parameter can be introduced. A specific deliverable “look-up tables” indicates the
codes to be used in the XML file.
Example with “optional value”:
<OPTrackParameter ID="ILL_InteropGauge" IsApplicable="Y" Value="10" OptionalValue="GA" />
<OPTrackParameter ID="ILL_MultiNatGauge" IsApplicable="Y" Value="30" OptionalValue="GB2"
/>
In this example, the code «10» provided for the parameter «International Gauge» which XML name is "ILL_InteropGauge" corresponds to gauge GA.
Likewise, the code «30» provided for the parameter «Multinational Gauge» which XML name is "ILL_MultiNatGauge" corresponds to gauge GB2.
The list below indicates the hierarchy of main parameter groups and subgroups. The network of each Member State is described in OPs and SoLs. A SoL is composed of one or several running tracks while an OP can have running track(s) and/or siding(s). Specific parameters must be fulfilled depending if the RINF element is a SoL or an OP.
The RINF parameters are organised as follows:
1.1.0.0.0.6 SOLNature / Nature of Section of Line
Parameters below until 1.1.1.2 belong to the group of infrastructure parameters
IPP_NCLoadCap /National classification for load capability
IPP_HSLMCompliant/Compliance of structures with the High Speed Load Model (HSLM) dynamic load model
IPP_StructureCheckLoc/Railway location of structures requiring specific checks 1.1.1.1.2.4.4 IPP_StructureCheckDocRef /Document with the procedure(s) for static and
dynamic route compatibility checks 1.1.1.1.2.5 IPP_MaxSpeed / Maximum permitted speed 1.1.1.1.2.6 IPP_TempRange / Temperature range 1.1.1.1.2.7 IPP_MaxAltitude / Maximum altitude
1.1.1.1.2.8 IPP_SevereClimateCon / Existence of severe climatic conditions
ILL_InteropGauge / Interoperable gauge 1.1.1.1.3.2 ILL_MultiNatGauge / Multinational gauges 1.1.1.1.3.3 ILL_NatGauge / National gauges 1.1.1.1.3.1.1 ILL_Gauging_/ Gauging
points requiring specific checks
1.1.1.1.3.7 ILL_MinRadHorzCurve / Minimum radius of horizontal curve
ILR_ECBDocRef / Document with the conditions for the use of eddy current brakes
1.1.1.1.7.3 IHS_AccelerationLevelCrossing / Acceleration allowed at level crossing 1.1.1.1.7.4 IHS_HABDExist /Existence of trackside hot axle box detector (HABD) 1.1.1.1.7.5 IHS_TSIHABD/Trackside HABD TSI compliant
IHS_HABDID/Identification of trackside HABD
IHS_HABDGen/Generation of trackside HABD 1.1.1.1.7.8 IHS_HABDLoc/Railway location of trackside HABD
1.1.1.1.7.9 IHS_HABDDirection/Direction of measurement of trackside HABD 1.1.1.1.7.10 IHS_RedLights/Steady red lights required
1.1.1.1.7.11 IHS_QuietRoute / Belonging to a quieter route
1.1.1.1.8.8 ITU_CrossSectionArea / Cross section area 1.1.1.1.8.8.1 ITU_TSITunnel / compliance of the tunnel with INF TSI
1.1.1.1.8.8.2 ITU_TunnelDocRef /
Reference of to a document
available from the IM with precise
description of the tunnel
1.1.1.1.8.9 ITU_EmergencyPlan / Existence of emergency plan 1.1.1.1.8.10 ITU_FireCatReq / Fire category of rolling stock required
1.1.1.1.8.11 ITU_NatFireCatReq / National fire category of rolling stock required
Parameters below until 1.1.1.3 belong to the group of energy parameters
1.1.1.2.2.1.3 ECS_Umax2/Umax2 for lines referred to in sections 7.4.2.2.1 and 7.4.2.11.1 of Regulation (EU) 1301/2014.
1.1.1.2.2.5 ECS_MaxWireHeight / Maximum contact wire height 1.1.1.2.2.6 ECS_MinWireHeight / Minimum contact wire height
1.1.1.2.4.2.2 EOS_InfoSystem / Information on system separation 1.1.1.2.4.3EOS_DistSignToPhaseEnd/Distance between signboard and phase separation ending
1.1.1.2.5.3 ERS_AutoDropRequired / Automatic dropping device required
Parameters below until 1.2 1.1.1.4 belong to the
group of CCS parameters
1.1.1.3.2.3 CPE_Infill / ETCS infill necessary for line access 1.1.1.3.2.4 CPE_InfillLineSide / ETCS infill installed lineside
1.1.1.3.2.5 CPE_NatApplication / ETCS
national packet 44 application implemented
1.1.1.3.2.6 CPE_RestrictionsConditions /
Existence of operating restrictions or
conditions 1.1.1.3.2.7
CPE_OptionalFunctions /
Optional ETCS functions
CRG_NumActiveMob / Advised Required number of active GSM-R mobiles (EDOR) or simultaneous communication session on-board for ETCS Level 2 (or level 3) needed to perform radio block centre handovers without having an operational disruption
1.1.1.3.3.3.3 CRG_GPRSAreaOfImpl / Area of implementation of GPRS 1.1.1.3.3.4 CRG_Needof555 / Use of group 555
1.1.1.3.3.5 CRG_RoamingAgreement / GSM-R networks covered by a roaming agreement 1.1.1.3.3.6 CRG_RoamingPublic / Existence of roaming to public networks
1.1.1.3.3.7 CRG_RoamingPublicDetails / Details on roaming to public networks 1.1.1.3.3.8 CRG_GSMRNoCoverage / No GSMR coverage
1.1.1.3.3.9 CRG_RadioCompVoice / Radio system compatibility voice 1.1.1.3.3.10 CRG_RadioCompData / Radio system compatibility data
CPO_Installed / Existence of other train protection, control and warning systems installed
CPO_MultipleRequired / Need for more than one train protection, control and warning system required on-board
1.1.1.3.7.1.4 CTD_TCLimitation/Section with train detection limitation, only for the French network
1.1.1.3.7.8 CTD_MinFlangeThickness / Minimum
permitted thickness of the flange 1.1.1.3.7.9
CTD_MinFlangeHeight / Minimum permitted
height of the flange 1.1.1.3.7.10
CTD_MaxFlangeHeight / Maximum permitted
height of the flange 1.1.1.3.7.11
CTD_MinAxleLoad / Minimum
permitted axle load
1.1.1.3.7.11.1 CTD_ MinAxleLoadByVehicleCat / Minimum permitted axle load per category of vehicle
1.1.1.3.7.12 CTD_TSIMetalFree / TSI compliance of rules for metal-free space around wheels 1.1.1.3.7.13 CTD_TSIMetalConstruction / TSI compliance of rules for vehicle metalconstruction 1.1.1.3.7.14 CTD_TSIFerroWheelMat / TSI compliance of Ferromagnetic characteristics of
wheel material required
brake blocks
1.1.1.3.7.22 CTD_TSIShuntDevices / TSI compliance of rules on shunt assisting devices 1.1.1.3.7.23 CTD_TSIRSTShuntImpedance/ TSI compliance of rules on combination of RST
characteristics influencing shunting impedance
1.1.1.3.11.3 CBP_BrakePerfDocRef/ Documents available by the IM relating to braking performance
COP / Other CCS related parameters
COP_Tilting / Indication whether titling functions are supported by ETCS
1.2.0.0.0.3 OPTafTapCode / OP TAF TAP primary code 1.2.0.0.0.4 OPType / Type of Operational Point
1.2.0.0.0.4.1 OPTypeGaugeChangeover / Type of track gauge changeover facility 1.2.0.0.0.5 OPGeographicLocation / Geographical location of Operational Point 1.2.0.0.0.6 OPRailwayLocation / Railway location of Operational point
1.2.1.0.2.3 IPP_FreightCorridor / Part of a Railway freight corridor
ILL_InteropGauge / Interoperable gauge 1.2.1.0.3.2 ILL_MultiNatGauge / Multinational gauges 1.2.1.0.3.3 ILL_NatGauge / National gauges 1.2.1.0.3.4 ILL_Gauging_/ Gauging
1.2.1.0.5.6 ITU_EmergencyPlan / Existence of emergency plan 1.2.1.0.5.7 ITU_FireCatReq / Fire category of rolling stock required
1.2.1.0.5.8 ITU_NatFireCatReq / National fire category of rolling stock required 1.2.1.0.5.9 ITU_ThermAllowed/Diesel or other thermal traction allowed
1.2.1.0.6.4 IPL_Length / Usable length of platform 1.2.1.0.6.5 IPL_Height / Height of platform
1.2.1.0.6.6IPL_AssistanceStartingTrain / Existence of platform assistance for starting train 1.2.1.0.6.7 IPL_AreaBoardingAid / Area of use of the platform boarding aid
OPSidingIdentification / Identification of siding 1.2.2.0.0.3 IPP_TENClass / TEN classification of siding
1.2.2.0.4.5 ITS_SandRestocking / Existence of sand restocking 1.2.2.0.4.6 ITS_ElectricShoreSupply / Existence of electric shore supply
(SRT)
1.2.2.0.5.8 ITU_NatFireCatReq / National fire category of rolling stock required
ECS_MaxStandstillCurrent/Maximum current at standstill per pantograph
RUL_LocalRulesOrRestrictions / Existence of rules and restrictions of a strictly local nature
Relations between parameters
Parameters are described in Table 1 of the Annex of RINF Regulation [36]. This table will not be copied in this guide, nor the status “core parameter” or “needed for the RC”, nor the deadline for the provision by the NRE/IM of the parameter.
Table 5 of this guide (see 5.1) gives information on relationships between parameters. Parameters are mandatory if applicable. The “applicability” of parameters can depend on value in relation to TSI or value of other primary parameters. E.g.:
parameter 1.1.0.0.0.1 (“IM Code“) is applicable in all cases and mandatory
1.1.2.2.6 (“Minimum contact wire height”) is applicable (“Y”) only if “Overhead contact line (OCL)” is selected in 1.1.1.2.2.1.1 and then mandatory to be provided.
The guide provides also explanation on the “specific applicability” of some of them.
Three groups of parameters need to be used with a “Set” attribute each time the ”parent” parameter is repeated with a different value. They have to be provided at the level of each track in a SoL.
The XML attribute called “Set” must be declared at the parent and children level with the same
keyword value.
The parameters represented by a set group have to be declared for each “parent” present on a
track, the applicability and values are entered for each system described.
Even though all the parameters are set in the XML file to applicable=”N” or “NYA”, the RINF application still requires the ‘Set’ attribute to be declared and populated. The way to bypass this requirement is to declare the Set as Set=”null”.
The principles for the use of the set attribute are:
Any string of characters can be used as value of a set but it must be different from one set to another;
The value of a given set must be unique in a given track.
The parameters represented by a set group have to be declared for each system present on a track, the applicability and values are entered for each system described.
Even though all the parameters are set in the XML file to applicable=”N”, the RINF application still requires the ‘Set’ attribute to be declared and populated. The way to bypass this requirement is to declare the Set as Set=”null”.
The groups of “linked” parameters are the followings:
For each type of contact line declared (parameter 1.1.1.2.2.1.1: ECS_SystemType / Type of contact line system) the following full set has to be provided:
1.1.1.2.5.1 ERS_PowerLimitOnBoard / Current or power limitation on board required
For each level of ETCS (parameter 1.1.1.3.2.1: CPE_Level / ETCS level), the following full set has to be provided:
1.1.1.3.2.2 CPE_Baseline / ETCS baseline
For each type of train detection system (parameter 1.1.1.3.7.1CTD_DetectionSystem / Type of train detection system), the following full set has to be provided:
1.1.1.3.7.8 CTD_MinFlangeThickness / Minimum permitted thickness of the flange 1.1.1.3.7.9 CTD_MinFlangeHeight / Minimum permitted height of the flange 1.1.1.3.7.10 CTD_MaxFlangeHeight / Maximum permitted height of the flange
1.1.1.3.7.11.1 CTD_ MinAxleLoadByVehicleCat / Minimum permitted axle load per category of Vehicle
1.1.1.3.7.12 CTD_TSIMetalFree / TSI compliance of rules for metal-free space around wheels 1.1.1.3.7.13 CTD_TSIMetalConstruction / TSI compliance of rules for vehicle metal
construction
1.1.1.3.7.14 CTD_TSIFerroWheelMat / TSI compliance of Ferromagnetic characteristics of wheel material required
CTD_TSIMaxImpedanceWheelset / TSI compliance of maximum permitted impedance between opposite wheels of a wheelset
CTD_MaxImpedanceWheelset / Maximum permitted impedance between opposite wheels of a wheelset when not TSI compliant
composite brake blocks
1.1.1.3.7.22 CTD_TSIShuntDevices / TSI compliance of rules on shunt assisting devices 1.1.1.3.7.23 CTD_TSIRSTShuntImpedance/ TSI compliance of rules on combination of RST
characteristics influencing shunting impedance
Governance process of Table 5
Three groups contributed to the current development of the previous version of the guide and to the implementation of the RINF decision:
The Development WP acted as a ”board”, responsible for:
providing information on the RINF implementation, needs for change and/or improvement to the application guide (AG) and/or to the software;
agreeing principles of changes on the basis of the consensus (RINF implementation is not yet mature enough to give this group the power to take decision)
The users' group is the group of technical experts from NREs/IMs that is mainly helping ERA with the implementation of IT databases;
The RINF Network WG is the group composed of NREs. The aim of this group is to share feedback on the implementation, on the understanding of the guide.
Principles of draft modifications were presented and first discussed in the Users Group. The result was sent to all participants of all the RINF groups (RINF Development WP, RINF Network WG) for consultation before the following common meeting.
If participants of the common meeting agree to the principles of changes presented, ERA introduced them in the next version of the application guide.
The Agency is now regularly organising common meetings (Joint RINF meetings) of the Development WP and of RINF Network WG for the implementation of the RINF regulation. The Application guide, including table 5, is one of the deliverables that will be under the management of the RINF Change Management Board that have to be established.
PRINCIPAL RULES FOR THE RINF APPLICATION
The principles listed below form the basis of the functional and non-functional requirements of the RINF system.
There is only one Entity in Charge of the register of Infrastructure (NRE) per Member State, acting as the centre point of data submissions to the RINF application. It is up to the NREs to manage the consolidation of data from the various IMs local registers and database and form a single data submission for the RINF. This shall include all RINF data for this country, as required by the RINF regulation.
The RINF application is a web-based application that will be available over the Internet.
Only the RINF data specified in the RINF regulation have to be provided by the Member States’
Registers to the RINF application.
Results of a query submitted by RINF application users may not be provided immediately. It is acceptable that the results of some complex queries can be provided in the form of reports at a later point in time (no later than 24hours). The exact response times will depend on the complexity of the request. The users receive a URL with the requested RINF data via email as soon as the query results are available at the RINF application. Then, they can access the RINF application and retrieve the results of their queries.
Each member state network is described by the upload of a full dataset by NRE. It is not possible to upload partial data. In case of update of the description, it is necessary to upload a new full dataset containing the existing information and the new one. In the incipient phases of the project, MSs will be allowed to provide sets of data that do not have all mandatory parameters filled. This measure comes to help MSs in showing their progress in collecting and compiling RINF data.
Only the data provided within the last submitted dataset by the NRE will be available through the RINF application. All previously existing data (from previous datasets) shall be stored for 2 years from the date of withdrawal of the data and will not be available through the RINF application.
No information can be provided in the RINF datasets about railway infrastructure which is no longer in service. These data will be no more accessible through the RINF application. Within the RINF dataset, the NREs have the possibility to provide the following types of time-related information:
Information about the currently existing railway infrastructure
Information about railway infrastructure that will come into service in the future
Information about currently existing railway infrastructure that will cease to operate in the future
No actual documents or other file attachments are included in the RINF datasets.
Access to the RINF data is controlled: authentication is necessary (e.g., username/password) before users can access RINF data through the RINF application.
No restrictions will be implemented once access granted: users logged-in to the RINF application shall have access to all RINF data of all countries.
Railway Undertaking Representative is a user category introduced by the RINF Regulation. This user can export details of a route, can generate a certificate for a specific route and can be notified on data updates.
A specific module within the RINF application was available for supporting the management of datasets (XML files) at the national level. For IMs use, it allows to create/edit RINF data set and to upload to the NRE. The same module allows the NRE to merge multiple datasets from different IMs into a single dataset. These two functionalities were developed as tools facilitating the implementation of the RINF Decision. The module is not currently updated for allowing IMs to create/edit RINF data set according to the RINF Regulation. There is no obligation to use this module. It depends on the national implementation strategy.
General
Governance is an important aspect to be considered for the implementation and the future operation of RINF. This can be divided in two major areas:
Governance for the implementation of the RINF system, including the business processes, software development, the testing and validation, and implementation of the various sub-systems that will provide the RINF set of data.
Governance for the maintenance of the RINF system, in order to guarantee the availability and integrity of RINF data.
Of course, responsibility for the implementation and maintenance of the system lies with the organisation implementing the respective system component. In this respect, another distinction has to be made between the Governance for the implementation and maintenance of:
The Member States’ Registers, implemented by entities in charge of RINF (NREs) nominated by Member States, hosted in each country’s premises,
The RINF application, implemented and hosted by ERA;
The artefacts based on which the NREs will base the implementation of the system for RINF purpose.
RINF application
The European Railway Agency (ERA) implements and hosts the RINF application.
In this respect, a web application is implemented at ERA level, for providing the basic functionalities described in the EC Decision, such as search page with filters and search results, user registration, etc. The database of the RINF application is a collation of the datasets sent by the Member States.
ERA implements and maintains the RINF application together with a contracted IT supplier. ERA chairs regular meetings with the entities in charge of RINF for implementation and maintenance of the RINF.
Team organisation
The implementation of the RINF Application as well as the activities related to its production operation (roll-out support, corrective and evolutive maintenance) will be undertaken by ERA with the assistance of its IT contractor. Some general concepts of this working methodology are provided here:
ERA Business Managers will be responsible for providing the overall Vision as well as the requirements from a business point of view. They will also be responsible for validating the deliverables (use cases, prototype, software application, etc.) that will be prepared by the IT contractor.
ERA Project Manager will be responsible for monitoring the progress of the project and mitigating risks.
ERA will be responsible for validating the technical deliverables prepared by the contractor (software architecture, test management, source code, etc.).
ERA Service Desk will be responsible for handling the technical communications with the technical experts of the Member States’ Registers, and for resolving any technical issues that may arise in the communication between the RINF application and the NRs.
RINF application Maintenance
All components installed within the environment of the RINF application (web application, database, web services, etc.) will be maintained by ERA. ERA will be responsible for the following tasks:
Maintenance at operational conditions and support:
Maintain look-up tables which provide the actual valid values of parameters with predescribed values.
Maintain the central database, run regular backup and clean-up tasks, communicate on quality of operations.
Perform standard maintenance tasks on the servers hosting the application (check file systems and logs, create backups, etc.).
Resolve any issues that emerge in the RINF web application
Organise help desk to provide support to entities in charge of RINF and users.
Management of changes:
Establish formal change management process.
Update the RINF data scheme if relevant.
Assist any new MS in connecting with the RINF application.
Maintain the Project and Infrastructure Documentation.
Registers at Member State level
Roles and responsibilities are defined in the RINF Regulation:
article 2 for the Member State,
article 4 for the NRE and the IM regarding the collection and the insertion of the data depending on the date of 1st January 2021,
article 5 for the IM regarding the accuracy, completeness, consistency and timeliness of data in the RINF Application
NREs and Agency responsibilities
Communication between RINF application and NREs
Each NRE will be responsible for the following (31 December 2020):
Prepare the dataset (XML file) comprising the full RINF information of the Member State including validation through data quality checks.
Submit the RINF dataset to the central database at ERA.
Follow-up with ERA relating to any issues on failing validation or upload.
Define the list of domestic border points, keep it updated and forward it to the Agency
Manage the data on domestic border points ERA will be responsible for the following:
Provide relevant documentation relating to maintenance and evolution of RINF.
Manage the list of MS border points
Manage reference list of domestic border points to be used in the validation process
Provide validation mechanism for the NREs to check the quality of their datasets before submitting them to the central database.
Facilitate the dataset uploading, through a web interface available only to NRE users,
Advise the NRE responsible of any problem.
Provide visibility on quality of upload process toward NREs, and on quality of data towards users.
In order to fulfil the above responsibilities, software modules at ERA will implement the following functionalities:
Receive from the NREs the XML files with the RINF data.
Validate the structure of the XML files against:
The predefined structure of the XSD file (format of fields, mandatory/optional, size of data, etc.), and
The business rules specified for checking the quality of the provided data (e.g., the name of an OP at start of SoL exists as OP within the dataset).
Logging any errors in the validation.
Reporting success/failure (with respective errors if any) back to the NREs.
Responsibility for the correctness and integrity of RINF data lies with the Member States. ERA shall finally check the validity of the submitted RINF data in terms of its conformity with the RINF scheme... Non-valid RINF data will be rejected by ERA, which will centrally record such non-valid RINF data submissions in logs on the RINF application server. In addition, the RINF application will automatically dispatch emails to the NREs when such non-valid submissions are detected.
This architecture requires that the RINF central database is fed with copies of the full sets of RINF data maintained at the Member States’ Registers. In particular, the NREs will prepare the XML files that encapsulate the full set of RINF data that is currently available at their Register (a current snapshot of all RINF information). Then, the NREs will submit this XML file to the central RINF repository, which will be collocated with the Common User Interface. This submission of datasets is carried out through manually uploading the compressed XML files to the RINF system via a dedicated interface provided for this purpose.
Figure 4 demonstrates the logical view of the RINF architecture. The RINF system provides two main interfaces. The first one is utilised by RINF users in order to connect to the RINF system and retrieve RINF information, and the other is utilised by the Member States’ NREs in order to provide/upload copies of their full RINF datasets. The basic use case is that the users connect via the internet to the RINF system through its user interface and they request to retrieve particular RINF data. The RINF application searches for the requested data centrally in its centralised database, retrieves the data, and presents it to the users.
Fig. 4 – RINF System
The NREs will maintain and be responsible for the management of their own RINF datasets at their respective Registers. The RINF system requires from NREs to be able to provide only copies of their full RINF dataset that are maintained in their Registers.
The XML file that encapsulates the full RINF dataset for a Member State’s Register is then validated against the corresponding XML Schema Definition (XSD). The responsibility for the correctness and completeness of the provided information is kept at the level of the NRE of the specific country, without prejudice to the roles and shared responsibilities between the national actors for the RINF implementation defined by each Member State. If the XSD validation fails, the data will be rejected and a report will be dispatched to the NRE listing the encountered errors.
The communication between the users and the RINF system is performed through the internet. Thus, in both cases the RINF architecture is transparent to the users. The users (i.e., RUs, IMs, Manufacturers, NSAs, etc.) open a web browser and connect to the RINF system via HTTP (or HTTPS for extra security if necessary). The RINF system provides access to the provided infrastructure information, as well as any additional functionalities and services. The RINF system queries the central RINF database and provides back to the users the proper RINF information.
The following deliverables are available on ERA extranet via the RINF specific folder and its
“Specific reference documents” page:
RINF xsd Schema
Lookup Values Dictionaries
The RINF xsd Schema and the Lookup Values dictionaries always correspond to the latest version of the Application Guide and the RINF application.
Data Upload & Validation & import Module (Data Management)
The RINF Data Management module is a software application that will be used by the NREs for uploading, validating their RINF datasets before the import and then import.
The rules of validation of the submitted datasets are described in the “RINF Data Validation Guide”
available via the RINF extranet specific page.
RINF Data Life Cycle
The RINF data life cycle involves the following stages:
The RINF data of a particular Member State is collated by the NRE into an XML formatted file, following the agreed structure (XSD) and business rules.
The XML file is uploaded to the Agency’s servers. For this purpose, a dedicated storage area
is made available on the Agency’s servers for each Member State (NRE).
The uploaded XML file is validated by the system, in order to approve the import of the data into the RINF database. The validation will include business rules and quality checks (format of data, management of reference lists, etc.).
Upon successful validation, the data can be imported into the RINF database if the NRE decided so.
Any existing data for the particular Member State will be deleted with every new import performed by the NRE.
The files that are successfully imported are archived in the Agency for future reference.
According to the Regulation, after 1st Jan 2021, the XML formatted file should/ shall be then directly uploaded in the RINF application by the IM.
Validation
In order to perform a validation of RINF data, each NRE will need to follow these steps:
The NRE will connect to the data management module and upload the RINF dataset, containing the RINF data of the particular Member State.
After the data transfer has been completed, the NRE will access the Validation web application, containing a validation form (authorised access only). The validation form will present the list of all files currently stored in the online storage area of that MS, and also a visual indication of whether a dataset import is pending.
The NRE will select for validation one of the files presented in the validation Form.
Alternatively, the user has the option to specify whether the file should also be imported after successful validation (this step additionally ask the user to confirm the selection since it will not be possible to deselect the file selected for import).
The Validation module validates the uploaded file and presents a report with the validation results.
a. If the option for the file to be imported was selected and the validation succeeded, then the file will be moved to a secure location in the file system and the data imported and displayed in the RINF application. From this point onward, the file cannot be accessed.
Restrictions
The following restrictions apply for the Validation module:
Each NRE user can only access the file area which is allocated to his MS. No access is provided to files from other MS.
Each Member State can only have one dataset file pending for import. It is not possible to
select “Validate & Import” if another file is already pending import.
Once a dataset file is pending import, it is not possible to undo the forthcoming import
Preproduction environment
The same version of the RINF application as the one installed in production is installed in a preproduction environment and available for NREs and IMs to test their files. This will ensure that the datasets are valid and adhere to the specified business rules and therefore they will not be rejected by the importing mechanism of the production environment.
STRATEGY OF UPGRADING THE RINF APPLICATION
Article 2.3. of the new RINF Regulation:
The new release of the RINF application, implementing the RINF Regulation, is planned to be placed in
“preproduction environment” in August 2019.
In addition with the requirements of the RINF Regulation.
The Agency has adapted the validation process to allow a backward compatibility. Xml files compatible with the previous Decision and currently used by NREs will be go on validated by the RINF application.
A new functionality called “reference documents management” is available and allow NREs to upload
documents whose references are given by new parameters.
- The new visualisation (via ArcGIS) is stable.
Article 6 of the RINF Regulation foresee the following developments: see copy of the article below.
“1. The Agency, taking into account the result of a cost-benefit analysis, shall update the RINF application by 1 January 2021 in order to:
streamline the process of updating data in the RINF Application in order to allow infrastructure managers to update information as soon as it becomes available;
improve the description of the network so as to display its geometry accurately;
provide information regarding possible routing on the network;
provide means for alerting railway undertakings regarding changes in the RINF Application relevant to them.
By 16 January 2022, the Agency, taking into account the result of a cost-benefit analysis, shall update the RINF application to enable the collection and insertion of information necessary for the Route Book referred to in Appendix D2 to Commission Implementing Regulation xxx (OPE TSI). Each Member State shall ensure that its register of infrastructure provides the information necessary for the Route Book one year after the RINF Application has been updated.
Further developments of the RINF application may create a data system feeding into all electronic information flows in respect of the Union rail network.”
These further developments are not in the scope of this current guide
APPENDICES
In order to facilitate the provision of data, as interim solution in case of missing data, it was proposed to use a Not Yet Available (NYA) attribute value in the RINF set of data to indicate the non-availability of data. Providers of data will be duly informed three month in advance of the removal of this option when decided.
A parameter is mandatory to be provided when it corresponds to a core parameter (defined in table 1 of the RINF Regulation) or when the corresponding item exists on the network that is described in accordance with the deadlines in Table 1 of the RINF Regulation. In this case, the possible allowed values for the applicability are Y or NYA (not yet available).
The status “Mandatory” has been deleted from the description of parameters in table 5.
When a parameter is not identified as a core parameter, the possible allowed values for the applicability are N, Y, NYA. It is not mandatory to provide an xml line for this kind of parameters.
Please note that:
The validation of any xml file requires the provision of at least a line for each parameter whose applicability status is ”Y” or “NYA”.
It is allowed, until 16 January 2020, not to provide an xml line for new parameters whose submission deadline is 16 January 2020.
Please note that:
The parameters deleted in the RINF Regulation will be kept and stay able to be imported until 2020. They will be withdrawn after 16 January 2020
There is one exception we have decided not to accommodate.
Most of you have already provided values for parameter 1.1.1.3.7.19 / TSI Compliance of rules on sand characteristics / SOL Track Parameter CTD_TSISandCharacteristics. This parameter is only applicable if the nominal track gauge corresponds to 1520 mm. CCS TSI: 3.1.4.2 of Annex A, index 77 that is the document that describes the TSI conditions of compliance indicates an open point for 1435 mm gauge. Any value indicating TSI compliance is wrong. The applicability of the parameter for other values than “1520” should be “not applicable”.
The validation process will indicate:
Parameter TSI Compliance of rules on sand characteristics - “CTD_TSISandCharacteristics”
The parameter does not respect the following applicability rule(s):
The parameter has to be defined as applicable when the following condition is met: Both of the following rules are satisfied: Parameter Type of train detection system - "CTD_DetectionSystem" has a value equal to "10". Parameter Nominal track gauge - "ITP_NomGauge" has a value equal to "40".
There is also a change regarding the unique OP Identification format of the Border Point. The validation
process will not accept other values instead of these starting with EU….
Please note that:
CharacterString means any sequence of alphanumeric characters (Latin letters and Arabic figures) and other symbols and spaces.
Predefined CharacterString means the sequence of Latin letters, Arabic figures, symbols and spaces specified and organized in specific way.
Predefined list – list of values (Predefined CharacterString) settled as only possible for the selection; sometimes selected element requires introduction of the additional value in predefined format.
The following symbols mean: Y= yes, N= no, NYA= not yet available.
When [NN…..N] is used inside brackets, it represents a number.
In case the number is smaller than the maximum allowed value, it should not be prefixed with zero(s): example of valid entry for:
length of section of line where the format is [NNN.NNN]: [76.012] is valid but [076.012] is not valid;
Maximum permitted speed where the format is [NNN]: [80] is valid but [080] is not valid;
In case the number of decimals provided is less than the maximum allowed, the value is not rejected by the validation process: example of valid entry for;
geographical coordinates where the format is Longitude (±NN.NNNN), (±45.1234) is valid but also (±45.123).
When the number of an EC declaration of verification is required the data presentation is: CC/RRRRRRRRRRRRRR/YYYY/NNNNNN
§ CC Country code (2 letters) based on a standard ISO 3166 alpha-2 except for United Kingdom: UK
§ RRRRRRRRRRRRRR National registration number of the applicant. The legal registration/identification number, given either by Tax Office or by Commercial Register or some other authority that registers companies in Member State.
§ 14 digits, if number is shorter the first digits should be left blank-00, like in case of counter.
§ YYYY Year when document issued
§ NNNNNN 6 digits counter – unique number by applicant. The counter shall be progressive number to be incremented by one unit each time a declaration is issued. Every year the counter shall restart from zero. The counter is related to the issuing body
Example: BL/00001002036258/2009/000001
§ The validations performed by the system are the following:
The number of characters and the slashes must be provided in the following manner: [CC/RRRRRRRRRRRRRR/YYYY/NNNNNN]
The YYYY characters must be a number in the of 1900-2100.
The NNNNNN characters must be digits. The same data presentation will be used for the EI declaration of demonstration.
Please note also (as explained above in 2.2.8) that:
Date of validity of current data collected in RINF is the same as date of export from the MS’ registers of
infrastructure to the RINF application.
Validity dates in the future may be inserted in the RINF XML for Operational Point, Section of Line, Track, Siding, Tunnel and Platform. These dates are not described as attributes of parameter.
However, if an IM wants to publish a set of data concerning their future value, the separate validity of those data from the date in future may be given. Then the set of data of the ‘object’, where those data are included, has to be added to current values by repeating the ‘object’ with the label of the date of validity in future (see explanations for Common User Interface in 3.1.h).
Please note that some parameters are asking for documents. Only the references of these documents are required to be filled in the RINF application. The Agency is being developing a module for allowing this functionality. The principle is that the NRE will upload in the RINF application via this module, progressively, by IM, all the referenced documents which will be available via a link on the description page of the characteristics of the tracks.
|
Table 5: Characteristics of RINF parameters |
|
|
Number |
1 |
|
Title |
MEMBER STATE |
|
XML Name |
MemberStateCode |
|
General Explanation |
The name of the MS is not a parameter. The MS recognition is automatically derived from the data export delivered by each NRE. |
|
Applicable |
Y |
|
Can be repeated |
N |
|
Validation |
For each national RINF data shall be one member state defined. |
|
|
|
|
Number |
1.1 |
|
Title |
SECTION OF LINE |
|
Can be repeated |
Y |
|
General Explanation |
Each network shall be described using as many SoLs as necessary. Each SoL is generated and identified by OP IDs at start and at end. A SoL only belongs to one Line. |
|
Validation |
RINF data are valid with zero or more SoLs declared in it. |
|
Number |
1.1.0.0.0 |
|
Title |
Generic information |
|
Can be repeated |
N |
|
|
|
|
Number |
1.1.0.0.0.1 |
|
Title |
IM’s Code |
|
XML Name |
SOLIMCode |
|
Definition |
Infrastructure Manager means any body or undertaking that is responsible in particular for establishing and maintaining railway infrastructure or a part thereof. |
|
Applicable |
Y |
|
Can be repeated |
N |
|
Data presentation |
[AAAA] |
|
Explanations |
The Code is a unique identifier for the Infrastructure Manager and it shall be verified on national level. Each Section of Line may concern only one IM. |
|
Reference |
Article 3 (2) of Directive 2012/34/EU and article 3.4.2 of Decision (EU) 2018/1614 (EVR Decision) |
|
Validation |
No verification by RINF application. Check of the link between MS and IM’s Code must be done nationally. |
|
|
|
|
Number |
1.1.0.0.0.2 |
|
Title |
National line identification |
|
XML Name |
SOLLineIdentification |
|
Definition |
Unique line identification or unique line number within Member State |
|
Applicable |
Y |
|
Can be repeated |
N |
|
Data presentation |
CharacterString |
|
General explanations |
Each SoL can belong to only one national line. In case when SoL is the track connecting between OPs within big node (resulting from division of big station into several smaller) the line can be identified using the name of this track. |
If the IM is subject to TAF/TAP TSIs, it corresponds to the code used in TAF/TAP TSIs.
In other cases, it corresponds to the "organisation code” assigned by the Agency for the specific needs of the RINF
|
Number |
1.1.0.0.0.3 |
|
Title |
Operational Point at start of Section of Line |
|
XML Name |
SOLOPStart |
|
Definition |
Unique OP ID at start of Section of Line (kilometres increasing from start OP to the end OP). |
|
Applicable |
Y |
|
Can be repeated |
N |
|
Data presentation |
Predefined CharacterString: [AA+AAAAAAAAAA] = country code (ISO) + alphanumeric OP code |
|
General explanations |
Each SoL may have only one start OP, and each OP has unique OP ID within the MS. The “uniqueOPID” is defined in parameter 1.2.0.0.0.2. Each SoL has the principal direction of the traffic defined by increasing kilometres running from the start OP to the end OP. That is why the start OP is always located at lowest kilometre of the line within the SoL. Data collected in the UK in miles will be transformed to km for uploading to the RINF application. |
|
Validation |
OP ID must exist in the MS file of RINF. The value of this parameter must be different from 1.1.0.0.0.4. No validation will be performed by RINF application regarding which is the start and which the end OP. This requires national verification. |
|
|
|
|
Number |
1.1.0.0.0.4 |
|
Title |
Operational Point at end of Section of Line |
|
XML Name |
SOLOPEnd |
|
Definition |
Unique OP ID at end of Section of Line (kilometres increasing from start OP to the end OP) |
|
Applicable |
Y |
|
Can be repeated |
N |
|
Data presentation |
Predefined CharacterString: [AA+AAAAAAAAAA] = country code (ISO) + alphanumeric OP code |
|
General explanations |
Each SoL may have only one end OP, and each OP has unique OP ID within the MS. The “uniqueOPID” is defined in parameter 1.2.0.0.0.2. Each SoL has the principal direction of the traffic defined by increasing kilometres running from the start OP to the end OP (which later is the reference for definition of the traffic direction for each track of the SoL). That is why the end OP is always at highest kilometre of the line within the SoL. Data collected in the UK in miles will be transformed to km for uploading to the RINF application. |
|
Validation |
OP ID must exist in the MS file of RINF. The value of this parameter must be different from 1.1.0.0.0.3 |
|
|
No validation will be performed by RINF application regarding which is the start and which the end OP. This requires national verification. |
|
|
|
|
Number |
1.1.0.0.0.5 |
|
Title |
Length of section of line |
|
XML Name |
SOLLength |
|
Definition |
Length between operational points at start and end of section of line. |
|
Applicable |
Y |
|
Can be repeated |
N |
|
Data presentation |
Predefined CharacterString: [NNNN.NNN] |
|
Explanation on data presentation: The distance is given in kilometres with decimals of 0,001. Data collected in the UK in miles will be transformed to km for uploading to the RINF application. |
|
|
General Explanations |
The length of SoL is theoretical distance between centre points of Ops which are selected in such a way to represent the average value for all tracks within the SoL. It is advised to include distances applied by IM for commercial purposes. |
|
Validation |
No validation will be performed by RINF application regarding the length of SoL. This requires national verification. |
|
|
|
|
Number |
1.1.0.0.0.6 |
|
Title |
Nature of Section of Line |
|
XML Name |
SOLNature |
|
Definition |
Kind of Section of Line expressing size of presented data which depends on fact whether it connects OPs generated by division of a big node into several OPs or not. |
|
Applicable |
Y |
|
Can be repeated |
N |
|
Data presentation |
Single selection from the predefined list: Regular SoL Link |
|
Data Presentation explanation: A link is to allow a train to go from an OP to another OP without a “regular section of line” between them. |
|
|
Validation |
If the value of this parameter is “Link”, then for all tracks belonging to this SoL, all the parameters of the following groups of parameters are not applicable: |
1.1.1.1 Infrastructure subsystem
1.1.1.2 Energy subsystem
1.1.1.3 Control-command and signalling subsystem
|
|
1.1.1 |
|
|
RUNNINGTRACK |
|
|
SOLTrack |
|
Can be repeated |
Y |
|
Explanation |
There might be more than one track within the Section of Line, so then the whole set of data for track has to be repeated for each track within the SoL. |
|
|
|
|
|
1.1.1.0.0 |
|
|
Generic information |
|
Can be repeated |
N |
|
Explanation |
Each track may have only one set of ‘Generic information’. |
|
|
|
|
Number |
1.1.1.0.0.1 |
|
Title |
Identification of track |
|
XML Name |
SOLTrackIdentification |
|
Definition |
Unique track identification or unique track number within Section of Line |
|
Applicable |
Y |
|
Can be repeated |
N |
|
Data presentation |
CharacterString |
|
General Explanations |
Each track shall have unique identification or number within the SoL. This number cannot be used for naming any other track in the same SoL. |
|
Validation |
The check of fact that ID is unique within SoL has to be done on national level (preferably by IM). |
|
Number |
1.1.1.0.0.2 |
|
Title |
Normal running direction |
|
XML Name |
SOLTrackDirection |
|
Definition |
The normal running direction is: |
|
Applicable |
Y |
|
Can be repeated |
N |
|
Data presentation |
Single selection from the predefined list: N O B |
|
Explanation on data presentation: N - same direction as in SoL O - opposite direction to as in SoL B - both directions N and O |
|
|
|
|
|
Number |
1.1.1.1 |
|
Title |
Infrastructure subsystem |
|
Can be repeated |
N |
|
Explanation |
For one track only one set of data on each subsystem is required. |
|
|
|
|
Number |
1.1.1.1.1 |
|
Title |
Declarations of verification for track |
|
XML Name |
IDE |
|
Can be repeated |
N |
|
Explanation |
This group of data concerns infrastructure subsystem on the specific track. There are two types of declarations included: EC declaration issued according to mandatory procedure defined by Interoperability Directive and EI declaration which may be issued according to the voluntary procedure defined by EC Recommendation [22]. |
|
|
|
|
|
1.1.1.1.1.1 |
|
|
EC declaration of verification for track (INF) |
|
|
SOL Track Parameter IDE_ECVerification |
|
|
Unique number for EC declarations following format requirements specified in the ‘Document about practical arrangements for transmitting interoperability documents’ |
|
Applicable |
Y/N/NYA |
|
Explanation on applicability: “Y” shall be selected in case when EC declaration was issued |
|
the same as the direction defined by the start and end of the SoL or
the opposite to the direction defined by the start and end of the SoL or
both directions defined for SoL.
|
Can be repeated |
Y |
|
Explanation on repeatability: The parameter may be repeated only when several EC declarations were issued related to the INF subsystem |
|
|
Data presentation |
Predefined CharacterString: [CC/RRRRRRRRRRRRRR/YYYY/NNNNNN] |
|
General explanations |
With the extension of scope according to Interoperability Directive 2008/57/EC, geographical scope of the INF TSI now includes all the networks (TEN and off-TEN) with the following nominal track gauges: 1435, 1520, 1524, 1600 and 1668 mm |
|
Reference concerning format |
‘Document about practical arrangements for transmitting interoperability documents' [23] |
|
Validation |
The validation is described before this Table |
|
Number |
1.1.1.1.1.2 |
|
Title |
EI declaration of demonstration for track (INF) |
|
XML Name |
SOL Track Parameter IDE_EIDemonstration |
|
Definition |
Unique number for EI declarations following the same format requirements as specified in the ‘Document about practical arrangements for transmitting interoperability documents’ |
|
Applicable |
Y/N/NYA |
|
Explanation on applicability: “Y” shall be selected in case when the demonstration was executed and EI declaration was issued. |
|
|
Can be repeated |
Y |
|
Data presentation |
Predefined CharacterString: [CC/RRRRRRRRRRRRRR/YYYY/NNNNNN]) |
|
General explanations |
It may happen that several EI declarations were issued – then parameter has to be repeated as many times as many declarations were issued. The procedure for demonstration that existing network fits to requirements of the TSIs is executed on voluntary basis, so when EI declaration do not exist then the parameter is optional. If EI declaration was not issued, then field shall be left empty. |
|
Reference |
|
|
Validation |
The validation is described before this Table, in section 2.3. |
|
|
|
Recommendation 2014/881/EU
Document about practical arrangements for transmitting interoperability documents'
|
Number |
1.1.1.1.2 |
|
Title |
Performance parameters |
|
XML Name |
IPP |
|
Can be repeated |
N |
|
Explanation |
For each track only the one set of ‘Performance parameters‘ may be presented. |
|
Number |
1.1.1.1.2.1 |
|
Title |
TEN classification of track |
|
XML Name |
SOL Track Parameter IPP_TENClass |
|
Definition |
Indication of the part of the trans-European network the line belongs to. |
|
Applicable |
Y/NYA |
|
Can be repeated |
Y |
|
Data presentation |
Single selection from the predefined list: Part of the TEN-T Comprehensive Network Part of the TEN-T Core Freight Network Part of the TEN-T Core Passenger Network Off-TEN |
|
Reference |
[24] Regulation (EU) No 1315/2013/EC Article 39 2. freight lines of the core network as indicated in Annex I: at least 22,5 t axle load, 100 km/h line speed and the possibility of running trains with a length of 740 m. |
|
|
|
|
Number |
1.1.1.1.2.1.2 |
|
Title |
TEN GIS identity |
|
XML Name |
SOL Track Parameter IPP_TENGISID |
|
Definition |
Indication of the GIS identity (GIS ID) of the section of TEN-T database to which the track belongs |
|
Explanation on definition |
|
|
Applicable |
Y/N/NYA Y if the answer to parameter 1.1.1.1.2.1 is not off TEN |
|
Can be repeated |
N |
|
Data presentation |
Characterstring |
|
References Example |
TENtec is the European Commission's information system to coordinate and support the Trans-European Transport Network Policy (TEN-T). For more details about the system and the legal background please follow the link to the TENtec Public Portal:
http://ec.europa.eu/transport/infrastructure/tentec/tentec-portal/
Τhe list of sections of the TEN network with their GIS IDs can be requested via MOVE- TENTEC-PUBLIC@ec.europa.eu |
|
|
|
|
Number |
1.1.1.1.2.2 |
|
Title |
Category of Line |
|
XML Name |
SOL Track Parameter IPP_LineCat |
|
Definition |
Classification of a line according to the INF TSI |
|
Explanation on definition: |
INF TSI classifies lines based on the type of traffic (traffic code). TSI categories of line shall be used for the classification of existing lines to define a target system so that the relevant performance parameters will be met. |
|
Applicable |
Y/N/NYA |
|
Explanation on applicability: Contrary to the Status of core parameter in the RINF Regulation, N can be used for the applicability for the following reasons. Technical scope of the INF TSI now includes all the networks (TEN and off-TEN) for nominal track gauges 1435, 1520, 1524, 1600 and 1668 mm Not applicable when track is not included in technical scope of the TSI. Not applicable when tables 2 or 3 of 4.2.1(7) of INF TSI are not usable on the UK network for Great Britain according to the specific case 7.7.17.1(2). |
|
|
Can be repeated |
Y |
|
|
Explanation on repeatability: When more than one value of the parameter has to be published, then parameter has to be repeated as many times as many values of the parameter will be published. |
|
Data presentation |
Single selection of the following traffic codes Passengers: P1 P2 P3 P4 P5 P6 P1520 P1600 Freight: F1 F2 F3 F4 |
|
|
F1520 F1600 |
|
Explanation on data presentation: The TSI category of line is a combination of traffic codes. For lines where only one type of traffic is carried (for example a freight only line), a single code can be used to describe the requirements; where mixed traffic runs the category will be described by one or more codes for passenger and freight in case of two types of traffic. Then the parameter is repeated if relevant. The combined traffic codes describe the envelope within which the desired mix of traffic can be accommodated. |
|
|
Example |
If a line is operated by passenger trains with speed of 250 km/h, local commuter trains with speed of 120 km/h and heavy freight trains in the night, then the best combination of traffic codes seems to be P2, P5 and F1. Then, the TSI category of line for this case would simply be P2-P5-F1. |
|
References |
INF TSI 4.2.1 |
|
Number |
1.1.1.1.2.3 |
|
Title |
Part of a Railway Freight Corridor |
|
XML Name |
SOL Track Parameter IPP_FreightCorridor |
|
Definition |
Indication whether the line is designated to a Railway Freight Corridor |
|
Applicable |
Y/N/NYA |
|
Explanation on applicability: Not applicable if the line is not part of an RFC |
|
|
Can be repeated |
Y |
|
Data presentation |
Single selection from the predefined list: Rhine-Alpine RFC (RFC 1) North Sea-Mediterranean RFC (RFC 2) Scandinavian – Mediterranean RFC (RFC 3) Atlantic RFC (RFC 4) Baltic-Adriatic RFC (RFC 5) Mediterranean RFC (RFC 6) Orient-EastMed RFC (RFC 7) North Sea-Baltic RFC (RFC 8) Rhine – Danube RFC (RFC 9) Alpine-Western Balkan RFC (RFC 10) Amber RFC (RFC 11) |
|
Explanation on data presentation: If a line belongs to several corridors, repeat the parameter. |
|
|
General Explanation |
A line can belong to one or several Rail Freight Corridor (RFC) |
|
References |
[6] Reg 913/2010/EC |
|
|
|
|
Number |
1.1.1.1.2.4 |
|
Title |
Load capability |
|
XML Name |
SOL Track Parameter IPP_LoadCap |
|
Definition |
A combination of the line category and speed at the weakest point of the track. |
|
Explanation on definition: |
At this step, RINF does not allow to enter additional data referred to additional speed regulations and operating requirements relating to locomotives (e.g., locomotive classes and associated maximum speed) or traffic types (e.g., maximum speed of freight traffic or passenger traffic). |
|
Applicable |
Y/NYA |
|
Can be repeated |
Y |
|
Explanation on repeatability: When more than one value of the parameter has to be published, then parameter has to be repeated as many times as many values of the parameter will be published. |
|
|
Data presentation |
Single selection from the predefined list of load models representing line category which is amended by value of speed [km/h] permitted for a specific load model: A [NNN] B1 [NNN] B2 [NNN] C2 [NNN] C3 [NNN] C4 [NNN] D2 [NNN] D3 [NNN] D4 [NNN] D4xL [NNN] E4 [NNN] E5 [NNN] Route Availability which is amended by value of speed [miles/h] permitted for a specific load model RA1 [NNN] RA2 [NNN] RA3 [NNN] RA4 [NNN] RA5 [NNN] RA6 [NNN] RA7 [NNN] RA8 [NNN] RA9 [NNN] RA10 [NNN] |
|
General explanation |
The load capability describes the weakest point of this track within this section of line (which is normally a bridge or other sub-track structure). It is expressed as a combination of the line category and speed permitted for trains exerting loads defined for this line category. The result of the classification process is set out in EN 15528:2008 (Annex A) and referred to in that standard as “Line Category”. It represents the ability of the infrastructure to withstand the vertical loads imposed by vehicles on the track for regular service as a combination of Line Category with a permitted speed according to EN 15528:2008 |
|
|
The Load capability for UK consists of RA and speed in miles per hour. RA shall be applied according to UK Railway Group Standard GE/RT8006, Issue Two, September 2010. More than one combination may be published for the same track if applicable, but it has to be done by repetition of the parameter with one value selected only – that is why ‘Y’ is given in line ‘Can be repeated’ For the following cases, it is not possible to use EN 15528:2008 categories of line classification: TSI categories of line P1 (passenger traffic at speeds greater than 250 Km/h) TSI categories of line P2 (passenger traffic at speeds greater than 200 Km/h and less than 250 Km/h) TSI categories of line P1520 and F1520 (passenger traffic or freight traffic at any speed) TSI categories of line P1600 and F1600 (passenger traffic or freight traffic at any speed) |
|
Example |
The set of selected data may include: B2-160, D4-120 and E5-100 When classifying infrastructure lines into line categories, the following options shall be used by the infrastructure manager to optimize freight traffic: Option 1: determination of the line category at maximum freight traffic speed (maximum 120 Km/h) Option 2: determination of a line category at an associated lower speed (less than the maximum freight traffic speed) Example of option 1 (Annex F of EN 15528:2008): In a given track, if the traffic is mixed, the local speed of the line is 90 Km/h and the determined line category is D4 at a maximum of 90 Km/h, the information displayed should be: D4/90. Example of option 2 (Annex F of EN 15528:2008): In a given track, if the traffic is mixed, the local speed of the line is 120 Km/h and the determined line category is C4 at a maximum of 120 Km/h and D4 at maximum of 90 Km/h, the information displayed should be: C4/120 and D4/90. |
|
References |
INF TSI: Paragraph 7.6 CR INF TSI: Paragraph 7.5 |
|
Number |
1.1.1.1.2.4.1 |
|
Title |
National classification for load capability |
|
XML Name |
SOL Track Parameter IPP_NCLoadCap |
|
Definition |
National classification for load capability |
|
Explanation on definition: |
National classification for load capability |
|
Applicable |
Y/N/NYA |
|
Can be repeated |
Y |
|
Data presentation |
Characterstring |
|
General explanation |
Some Networks are using National classification for load capability (instead of parameter 1.1.1.1.2.4 Load capability that provide load capability in accordance with EN 15528) (e.g. the French IM SNCF reseau is using the concept of “groupe Demeaux” with the following definition is “Groupe de classification de la voie tenant compte de la résistance de son armement en flexion verticale ». |
|
Example |
|
|
References |
Annex D1 OPE TSI |
|
|
|
|
Number |
1.1.1.1.2.4.2 |
|
Title |
Compliance of structures with the High Speed Load Model (HSLM) |
|
XML Name |
SOL Track Parameter IPP_HSLMCompliant |
|
Definition |
For sections of line with a maximum permitted speed of 200km/h or more information regarding the procedure to be used to perform the dynamic compatibility check |
|
Explanation on definition: |
|
|
Applicable |
Y/N/NYA Y if the maximum permitted speed of the running track is more than 200km/h and the structures within the section of line are all compatible with the High Speed Load Model (HSLM); information regarding the procedure to be used to perform the dynamic compatibility check shall be provided as well |
|
Can be repeated |
N |
|
Data presentation |
Single selection from the predefined list: Y/N |
|
General explanation |
|
|
Example |
|
|
References |
Annex D1 OPE TSI 4.2.7.1.2(2) of Regulation No 1299/2014 TSI INF HSLM is defined in EN 1991-2:2003/AC:2010 paragraphs 6.4.6.1.1 (3) to (6) inclusive |
|
|
|
|
|
|
|
Number |
1.1.1.1.2.4.3 |
|
Title |
Railway location of structures requiring specific checks |
|
XML Name |
SOL Track Parameter IPP_StructureCheckLoc |
|
Definition |
Localisation of structures requiring specific checks |
|
Explanation on definition: |
The railway location identifies the location of the structure in the system of reference of the line to which the track belongs |
|
Applicable |
Y/N/NYA |
|
Can be repeated |
Y |
|
Data presentation |
Predefined CharacterString: [±NNNN.NNN] |
|
explanation on Data presentation |
Explanation on data presentation: |
|
|
The location (generally the distance from the origin of the line to the centre) on a line is given in kilometres with decimals (precision of 0.001). Contrary to the regulation, the reference to the line is not needed: the parameter is still attached to the track of the line |
|
General explanation |
This information is to be linked with parameter 1.1.1.1.2.4.4 E.g. the IM A knows that its bridge X might have problems with combination of speed and load above a certain limit values Z, and for that the IM A has a specific procedure W for the check to be done; if the vehicle operation is intended to be within this case (above the limit Z), then RU shall proceed in accordance to the procedure W; therefore the bridge X shall be referred to in the parameter of the RINF: 1.1.1.1.2.4.3 / Railway location of structures requiring specific checks. Please Note that this is a hypothetic example, as the Agency doesn’t know the specific procedures of the IMs. It could be those bridges that have not been designed according to the HSLM dynamic load model. |
|
References |
|
|
|
|
|
Number |
1.1.1.1.2.4.4 |
|
Title |
Document with the procedure(s) for static and dynamic route compatibility checks |
|
XML Name |
SOL Track Parameter IPP_StructureCheckDocRef |
|
Definition |
Electronic document available in two EU languages from the IM stored by the Agency with: Or |
|
Applicable |
Y/N/NYA |
|
Can be repeated |
Y The references of the different documents can be described by repeating the parameter |
|
Data presentation |
Characterstring |
|
General explanation |
The document itself has to be upload by the NRE via the “reference document management” functionality. The reference of the document is provided for the parameter using the characterstring format. |
|
References |
Annex D1 OPE TSI |
|
|
|
precise procedures for the static and dynamic route compatibility checks;
relevant information for carrying out the checks for specific structures.
|
Number |
1.1.1.1.2.5 |
|
Title |
Maximum permitted speed |
|
XML Name |
SOL Track Parameter IPP_MaxSpeed |
|
Definition |
Nominal maximum operational speed on the line as a result of INF, ENE and CCS subsystem characteristics expressed in kilometres/hour. |
|
Explanation on definition |
‘Speed on the line’ shall be understood as speed on the track of the section of line in question. |
|
Applicable |
Y/NYA |
|
Can be repeated |
N |
|
Data presentation |
[NNN] |
|
Limit values |
min=0, max=500 |
|
References |
INF TSI: All HS and CR TSIs (ENE, CCS) |
|
Example |
When INF allows 160 km/h, ENE allows 100 km/h and CCS allows 120 km/h, the max permitted speed on this track of this section of line is 100 km/h. When for freight trains operation the maximum permitted speed is 100 km/h, and for passenger trains it is 160 km/h, as the value of maximum permitted speed shall be presented 160 km/h only. |
|
|
|
|
Number |
1.1.1.1.2.6 |
|
Title |
Temperature range |
|
XML Name |
SOL Track Parameter IPP_TempRange |
|
Definition |
Temperature range for unrestricted access to the line according to European standard. |
|
Applicable |
Y/NYA |
|
Can be repeated |
N |
|
Data presentation |
Single selection from the predefined list: T1 (-25 to +40) T2 (-40 to +35) T3 (-25 to +45) Tx (-40 to +50) |
|
Reference |
Temperature range according EN 50125-1 (1999) 4.3 |
|
Number |
1.1.1.1.2.7 |
|
Title |
Maximum altitude |
|
XML Name |
SOL Track Parameter IPP_MaxAltitude |
|
Definition |
Highest point of the section of line above sea level in reference to Normal Amsterdam’s Peil (NAP). |
|
Applicable |
Y/NYA |
|
Can be repeated |
N |
|
Data presentation |
[+/-][NNNN] |
|
General explanation |
Normaal Amsterdams Peil (NAP), called also Amsterdam Ordnance Datum, it is a vertical datum commonly in use in Europe as reference level for the description of the height of objects in relation to the sea level. The value of the parameter shall be given in metres, with tolerance of +/-100m. |
|
|
|
|
Number |
1.1.1.1.2.8 |
|
Title |
Existence of severe climatic conditions |
|
XML Name |
SOL Track Parameter IPP_SevereClimateCon |
|
Definition |
Climatic conditions on the line are severe according to European standard. |
|
Applicable |
Y/NYA |
|
Can be repeated |
N |
|
Data presentation |
Single selection from the predefined list: Y N |
|
Explanation on data presentation: ‘Y’ shall be selected in case when snow, ice and hail conditions (as defined in TSIs and European standards) indicate that climatic conditions are severe. ‘N’ to be selected otherwise. |
|
|
References |
EN 50125-1 (2014): 4.7 LOC&PAS TSI:4.2.6.1.2 CR LOC&PAS TSI: 4.2.6.1.5. |
|
Number |
1.1.1.1.3 |
|
Title |
Line layout |
|
XML Name |
ILL |
|
Can be repeated |
N |
|
Explanation |
For the specific track only one line layout may be described |
|
|
|
|
|
|
|
Number |
1.1.1.1.3.1.1 |
|
Title |
Gauging |
|
XML Name |
SOL Track Parameter ILL_Gauging |
|
Definition |
Gauges as defined in European standard or other local gauges, including lower or upper part. |
|
Applicable |
Y/NYA |
|
Can be repeated |
Y |
|
Explanation on definition |
Gauges as defined in European standard or other local gauges, including lower or upper part. In accordance with point 7.3.2.2 in Regulation (EU) 1302/2014, sections of lines of the United Kingdom of Great Britain network may not have gauge reference profile. |
|
Data presentation |
Single selection from the predefined list: GA GB GC G1 DE3 G2 GB1 GB2 |
|
|
BE1 BE2 BE3 FR-3.3 PTb PTb+ PTc FIN1 SEa SEc DE1 DE2 Z-GCD UK1 UK1[D] W6 FS S GHE16 GEA16 GEB16 GEC16 IRL1 IRL2 IRL3 GI1 GI2 GI3 GEE10 GED10 AFM 423 NL1 NL2 FR-3.4.1 FR-3.4.2 AFG AFM425 AFM427 M30 M80 Tram-train 2.40 Tram-train 2.65 Métrique BA Métrique SGV Métrique Cerd. GB:GČD GCZ3 GČD GEI1 GEI2 GEI3 GEC14 EBV1 EBV2_reduziert EBV2 EBV3_reduziert EBV3 EBV4 AF4.0 – EP AF4.1 – EP AF4.2 – EP AF4.0 – IP |
|
|
AF4.1 – IP AF4.2 – IP other |
|
Explainations on the use of this parameters |
Other values than the already identified in the list above are possible. They will be introduced by the Agency on request via a process of change request. The previous parameters related to the gauge will be deleted foolwing the mandatory provision of the “gauging” parameter foreseen by the RINF Regulation on 16 January 2020. |
|
References |
EN 15273-3 (2013): Annex C taking into account corrigendum A1. EN15273-3 (2013): Annex C and Annex D INF TSI: 4.2.3.1 |
|
|
|
|
Number |
1.1.1.1.3.1.2 |
|
Title |
Railway location of particular points requiring specific checks |
|
XML Name |
SOL Track Parameter ILL_GaugeCheckLoc |
|
Definition |
Location of particular points requiring specific checks due to deviations from gauging referred to in 1.1.1.1.3.1.1. |
|
Explanation on Definition |
The railway location identifies the location of the structure in the system of reference of the line to which the track belongs. This parameter is applicable when the conditions for the application of the gauge are not fulfilled (for example when the radius is 125 m and the minimum radius admitted for the gauge GC is 150 m). It can also be applicable when the IM wants to highlight also on a particular point and provide info via parameter 1.1.1.1.3.1.3 |
|
Applicable |
Y/N/NYA This parameter is applicable when the conditions for the application of the gauge are not fulfilled (for example when the radius is 125 m and the minimum radius admitted for the gauge GC is 150 m). It can also be applicable when the IM wants to highlight also on a particular point and provide info via parameter 1.1.1.1.3.1.3 This parameter could be also applicable when the gauge is infringed. This means that the obstacles are inside the infrastructure gauge. This case could happen for example for platforms where the platform does not fulfill the gauge. |
|
Can be repeated |
Y |
|
Data presentation |
Predefined CharacterString: [±NNNN.NNN] |
|
Explanation on data presentation: The location (generally the distance from the origin of the line to the centre) on a line is given in kilometres with decimals (precision of 0.001). Contrary to the regulation, the reference to the line is not needed: the parameter is still attached to the track of the line |
|
|
References |
|
|
|
|
|
Number |
1.1.1.1.3.1.3 |
|
Title |
Document with the transversal section of the particular points requiring specific checks |
|
XML Name |
SOL Track Parameter ILL_GaugeCheckDocRef |
|
Definition |
Electronic document available from the IM stored by the Agency with the transversal section of the particular points requiring specific checks due to deviations from gauging referred to in 1.1.1.1.3.1.1. Where relevant, guidance for the check with the particular point may be attached to the document with the transversal section. |
|
Explanations |
Only the reference of the document must be provided. The parameter must need to be repeated for each document to be referred. The document itself has to be upload by the NRE via the “reference document management” functionality. The reference of the document is provided for the parameter using the characterstring format. The parameter has to be repeated for providing the 2 different translations |
|
Applicable |
Y/N/NYA |
|
Can be repeated |
Y |
|
Data presentation |
CharacterString |
|
References |
|
|
Number |
1.1.1.1.3.4 |
|
Title |
Standard combined transport profile number for swap bodies |
|
XML Name |
SOL Track Parameter ILL_ProfileNumSwapBodies |
|
Definition |
Coding for combined transport with swap bodies as defined in UIC Code. |
|
Applicable |
Y/N/NYA |
|
Explanation on applicability: Contrary to the Status of core parameter in the RINF Regulation, N can be used. |
|
|
Can be repeated |
Y |
|
Data presentation |
Single selection from the predefined list: C 22 C 25 C 30 C 32 C 38 C 45 C 50 C 55 |
|
|
C 60 C 65 C 70 C 80 C 90 C 341 C 349 C 351 C 357 C 364 C 365 C 371 C 375 C 380 C 384 C 385 C 389 C 390 C 395 C 400 C 405 C 410 C 420 C 422 C 450 C S55 C S385 other |
|
Explanation on data presentation: The technical number is made up of the wagon compatibility code (1 letter) and the standard combined transport profile number (2 digits when width ≤ 2550 mm or 3 digits when, 2550 < width ≤ 2600 mm). |
|
|
Reference |
UIC Code 596-6 |
|
Number |
1.1.1.1.3.5 |
|
Title |
Standard combined transport profile number for semi-trailers |
|
XML Name |
SOL Track Parameter ILL_ProfileNumSemiTrailers |
|
Definition |
Coding for combined transport for semi-trailers as defined in UIC Code |
|
Applicable |
Y/N/NYA |
|
Explanation on applicability: Contrary to the Status of core parameter in the RINF Regulation, N can be used. |
|
Can be repeated |
Y |
|
Data presentation |
Single selection from the predefined list: P 22 P 25 P 30 P 32 P 38 P 45 P 50 P 55 P 59 P 60 P 65 P 70 P 80 P 90 P 341 P 349 P 351 P 357 P 364 P.365 P 371 P 375 P 380 P 384 P 385 P 390 P 395 P 400 P 405 P 410 P 420 P 422 P 450 P S55 P S385 other |
|
Explanation on data presentation: |
|
|
The technical number is made up of the wagon compatibility code (1 letter) and the standard combined transport profile number (2 digits when width ≤ 2500 mm or 3 digits when 2500 < width ≤ 2600 mm). |
|
Reference |
UIC Code 596-6 |
|
|
|
|
Number |
1.1.1.1.3.5.1 |
|
Title |
Specific information |
|
XML Name |
SOL Track Parameter ILL_SpecificInfo |
|
Definition |
Any specific information from the IM |
|
Explanation on definition |
This parameter allows the IM to provide plain text with specific information about the track |
|
Applicable |
Y/N/NYA |
|
Can be repeated |
|
|
Data presentation |
Characterstring |
|
References |
|
|
|
|
|
Number |
1.1.1.1.3.6 |
|
Title |
Gradient profile |
|
XML Name |
SOL Track Parameter ILL_GradProfile |
|
Definition |
Sequence of gradient values and locations of change in gradient |
|
Applicable |
Y/NYA |
|
Can be repeated |
Y |
|
Data presentation |
Predefined CharacterString: [±NN.N] ([±NNNN.NNN]) |
|
General explanation |
Data on the values of gradient along a SoL is given as a chain of information: Gradient (location) The first location corresponding to the start of the first value of the gradient is the centre point of start OP. If there are different values of the gradient, the parameter will be repeated. The last location will correspond to the point where the last value of the gradient starts. This value will be available until the centre point of the end OP. If gradient has only one value along the track, then only [+/-NN.N] is required. Gradient is expressed in mm/m; location is expressed in km of the line. Positive gradient (uphill) is marked with ‘+’ and negative gradient (downhill) is marked by ‘-‘. The order in the sequence shall be determined by the normal running direction on the specific track. If it is ‘B’ (see 1.1.1.0.0.2) then sequence shall follow the increasing kilometres of the line. Changes in gradient shall be registered only as far as necessary for train running calculations (minimum length of constant gradient shall be 500 m, the minimum change of gradient value shall be 0,5 mm/m). The required precision for gradient value is 0,5 mm/m, the required precision of location of the points of change of gradient is 10 m. The points of change of gradient are the points of vertical intersection of each vertical curve. |
|
References |
INF TSI: 4.2.3.3 HS TSI INF: 4.2.5 CR TSI INF: 4.2.4.3 |
|
Number |
1.1.1.1.3.7 |
|
Title |
Minimum radius of horizontal curve |
|
XML Name |
SOL Track Parameter ILL_MinRadHorzCurve |
|
Definition |
Radius of the smallest horizontal curve of the track in metres. |
|
Applicable |
Y/NYA |
|
Can be repeated |
N |
|
Data presentation |
[NNNNN] |
|
References |
INF TSI: 4.2.3.4 CR TSI INF: 4.2.4.4 |
|
Explanation |
To describe a straight section of line value ‘99999’ shall be used. |
|
|
|
|
Number |
1.1.1.1.4 |
|
Title |
Track parameters |
|
XML Name |
ITP |
|
Can be repeated |
N |
|
|
|
|
Number |
1.1.1.1.4.1 |
|
Title |
Nominal track gauge |
|
XML Name |
SOL Track Parameter ITP_NomGauge |
|
Definition |
A single value expressed in millimetres that identifies the track gauge |
|
Applicable |
Y/NYA |
|
Can be repeated |
N |
|
Data presentation |
Single selection from the predefined list: 750 1000 1435 1520 1524 1600 1668 other |
|
General explanation |
In case of multi-rail track, a set of data is to be published separately to each pair of rails to be operated as separate track (the whole set of parameters for the separate track has to be delivered – be careful then with the track identification). |
|
References |
INF TSI: 4.2.4.1 CR INF TSI: 4.2.5 HS INF TSI: 4.2.2 |
|
|
|
|
Number |
1.1.1.1.4.2 |
|
Title |
Cant deficiency |
|
XML Name |
SOL Track Parameter ITP_CantDeficiency |
|
Definition |
Maximum cant deficiency expressed in millimetres defined as difference between the applied cant and a higher equilibrium cant the line has been designed for |
|
Applicable |
Y/NYA |
|
Can be repeated |
N |
|
Data presentation |
[+/-] [NNN] |
|
Explanations on data presentation: In case of positive value of cant deficiency or zero symbol ‘+’ shall be applied. In case of negative cant deficiency symbol ‘-‘ has to be selected. Value of the cant deficiency shall be given in millimetres. In case of lateral uncompensated acceleration on a 1435 mm track gauge of 1.0 m/s2 the value of 153 mm may be published. |
|
|
References |
INF TSI: 4.2.4.3 HS INF TSI: 4.2.8 CR INF TSI: 4.2.5.4 |
|
|
|
|
Number |
1.1.1.1.4.3 |
|
Title |
Rail inclination |
|
XML Name |
SOL Track Parameter ITP_RailInclination |
|
Definition |
An angle defining the inclination of the head of a rail relative to the running surface |
|
Applicable |
Y/NYA |
|
Can be repeated |
N |
|
Data presentation |
[NN] |
|
General explanation |
This inclination is in most cases expressed for MS globally, but anyway it requires presentation for the specific track, when in one SoL more values occur. An angle defining the inclination of the head of a rail when installed in the track relative to the plane of the rails (running surface), equal to the angle between the axis of symmetry of the rail (or of an equivalent symmetrical rail having the same rail head profile) and the perpendicular to the plane of the rails. [NN] represents the denominator of the rail inclination expressed as 1/NN. The typical values are 1:20, 1:30, 1:40. |
|
References |
INF TSI:4.2.4.7 HS INF TSI: 4.2.11 CR INF TSI: 4.2.5.7 |
|
|
|
|
Number |
1.1.1.1.4.4 |
|
Title |
Existence of ballast |
|
XML Name |
SOL Track Parameter ITP_Ballast |
|
Definition |
Specifies whether track construction is with sleepers embedded in ballast or not. |
|
Applicable |
Y/N/NYA |
|
Y for
tracks with permitted speed (parameter 1.1.1.1.2.5) greater than |
|
|
Can be repeated |
N |
|
Data presentation |
Single selection from the predefined list: Y N |
|
General explanation |
This parameter is related to phenomena of ballast pick-up observed for the high speed traffic. |
|
Reference |
loc&Pas TSI 4.2.6.2.5 |
|
Comments |
Ballast pick-up is an open point in HS INF TSI and INF TSI: 4.2.10.3 The parameter is about the phenomenon, but not about the ballast itself. As so far any specifications for mitigation of the problem were disclosed, the only information from RINF will be data about the network where the problems may be faced. |
|
Number |
1.1.1.1.5 |
|
Title |
Switches and crossings |
|
XML Name |
ISC |
|
Can be repeated |
N |
|
|
|
|
Number |
1.1.1.1.5.1 |
|
Title |
TSI compliance of in service values for switches and crossings |
|
XML Name |
SOL Track Parameter ISC_TSISwitchCrossing |
|
Definition |
Switches and crossings are maintained to in service limit dimension as specified in TSI |
|
|
Y/NYA |
|
Can be repeated |
N |
|
Data presentation |
Single selection from the predefined list: Y N |
|
General explanation |
If for existing track at least one parameter has less strict value than specified in the TSI, then 'N' shall be selected. |
|
References |
INF TSI: 4.2.5 and 4.2.8.6 CR INF TSI: 4.2.6.2 HS INF TSI: 4.2.12 |
|
|
|
|
Number |
1.1.1.1.5.2 |
|
Title |
Minimum wheel diameter for fixed obtuse crossings |
|
XML Name |
SOL Track Parameter ISC_MinWheelDiaFixObtuseCrossings |
|
Definition |
Maximum unguided length of fixed obtuse crossings is based on a minimum wheel diameter in service expressed in millimetres. |
|
Applicable |
Y/NYA |
|
Can be repeated |
N |
|
Data presentation |
[NNN] |
|
General explanation |
The minimum TSI value is 330 mm and this shall be used as a default value unless advised otherwise. If the value of the wheel diameter is bigger than 330 mm, it has to be specified. |
|
Comments |
New lines are assumed to be compliant with the TSI INF. When the line is compliant to TSI the default value of 330 mm has to be presented |
|
References |
INF TSI: 4.2.5.3 CR INF TSI: 4.2.6.3; HS INF TSI: 4.2.12.3 |
|
|
|
|
Number |
1.1.1.1.6 |
|
Title |
Track resistance to applied loads |
|
XML Name |
ILR |
|
Can be repeated |
N |
|
|
|
|
Number |
1.1.1.1.6.1 |
|
Title |
Maximum train deceleration |
|
XML Name |
SOL Track Parameter ILR_MaxDeceleration |
|
Definition |
Limit for longitudinal track resistance given as a maximum allowed train deceleration and expressed in metres per square second. |
|
Applicable |
Y/N/NYA |
|
Explanation on applicability: ‘N’ shall be selected when specific track is part of a line which is not in the scope of the TSI. |
|
|
Can be repeated |
N |
|
Data presentation |
[N.N] |
|
General Explanation |
New lines are assumed to be compliant with the TSI INF. For TSI compliant lines the default value of 2.5 m/s2 shall be presented. If for the design of the track the braking forces were assumed on basis of the deceleration lower value than 2.5 m/s2, the applied value of the deceleration has to be specified. |
|
References |
INF TSI: 4.2.6 HS INF TSI: 4.2.13 CR INF TSI: 4.2.7 |
|
|
|
|
Number |
1.1.1.1.6.2 |
|
Title |
Use of eddy current brakes |
|
XML Name |
SOL Track Parameter ILR_EddyCurrentBrakes |
|
Definition |
Indication of limitations on the use of eddy current brakes. |
|
Applicable |
Y/NYA |
|
Can be repeated |
N |
|
Data presentation |
Single choice from the predefined list: allowed allowed under conditions allowed only for emergency brake allowed under conditions only for emergency brake not allowed |
|
Explanations |
The use of both brakes is allowed or not under exterior conditions (depending on the features of the train engines for example). The RINF can’t be filled without more precisions. |
|
References |
INF TSI: 4.2.6.2.2 (open point) CR INF TSI: 4.2.7.2.2 HS TSI: 4.2.13.1 |
|
|
|
|
Number |
1.1.1.1.6.3 |
|
Title |
Use of magnetic brakes |
|
XML Name |
SOL Track Parameter ILR_MagneticBrakes |
|
Definition |
Indication of limitations on the use of magnetic brakes. |
|
Applicable |
Y/NYA |
|
Can be repeated |
N |
|
Data presentation |
Single choice from the predefined list: allowed allowed under conditions allowed under conditions only for emergency brake allowed only for emergency brake not allowed |
|
References |
INF TSI: 4.2.6.2.2 (open point) CR INF TSI: 4.2.7.2.2 HS INF TSI: 4.2.13.1 |
|
|
|
|
|
|
|
Number |
1.1.1.1.6.4 |
|
Title |
Document with the conditions for the use of eddy current brakes |
|
XML Name |
SOL Track Parameter ILR_ECBDocRef |
|
Definition |
Electronic document available in two EU languages from the IM stored by the Agency with conditions for the use of eddy current brakes identified in 1.1.1.1.6.2. |
|
|
|
|
Applicable |
Y/N/NYA |
|
|
Y if the answer to the1.1.1.1.6.2 Use of eddy current brakes is “allowed under conditions” or “allowed under conditions only for emergency brake” |
|
Can be repeated |
Y |
|
Data presentation |
CharacterString |
|
Explanation |
If there exist conditions to allow the use of eddy current brakes. The document itself has to be upload by the NRE via the “reference document management” functionality. The reference of the document is provided for the parameter using the characterstring format. |
|
|
|
|
Number |
1.1.1.1.6.5 |
|
Title |
Document with the conditions for the use of magnetic brakes |
|
XML Name |
SOL Track Parameter ILR_MBDocRef |
|
Definition |
Electronic document available in two EU languages from the IM stored by the Agency with conditions for the use of magnetic brakes identified in 1.1.1.1.6.3. |
|
Applicable |
Y/N/NYA |
|
|
Y if the answer to 1.1.1.1.6.3 / Use of magnetic brakes is “allowed under conditions” or “allowed under conditions only for emergency brake”. |
|
Can be repeated |
Y |
|
Data presentation |
CharacterString |
|
Explanation |
If there exist conditions to allow the use of magnetic brakes. The document itself has to be upload by the NRE via the “reference document management” functionality. The reference of the document is provided for the parameter using the characterstring format. |
|
References |
|
|
Number |
1.1.1.1.7 |
|
Title |
Health, safety and environment |
|
XML Name |
IHS |
|
Can be repeated |
N |
|
Number |
1.1.1.1.7.1 |
|
Title |
Use of flange lubrication forbidden |
|
XML Name |
SOL Track Parameter IHS_FlangeLubeForbidden |
|
Definition |
Indication whether the use of on-board device for flange lubrication is forbidden |
|
Applicable |
Y/NYA |
|
Can be repeated |
N |
|
Data presentation |
Single selection from the predefined list: Y N |
|
|
|
|
Number |
1.1.1.1.7.2 |
|
Title |
Existence of level crossings |
|
XML Name |
SOL Track Parameter IHS_LevelCrossing |
|
Definition |
Indication whether level crossings (including pedestrian track crossing) exist on the section of line. |
|
Applicable |
Y/NYA |
|
Can be repeated |
N |
|
Data presentation |
Single selection from the predefined list: Y N |
|
General explanation |
Parameter concerns the level crossing of the railway with a road or a street. |
|
|
|
|
Number |
1.1.1.1.7.3 |
|
Title |
Acceleration allowed near level crossing |
|
XML Name |
SOL Track Parameter IHS_AccelerationLevelCrossing |
|
Definition |
Existence of
limit for acceleration of train if stopping or recovering speed close to a level
crossing expressed in a specific reference acceleration curve second. |
|
Applicable |
Y/N/NYA |
|
Explanation on applicability: Applicable only when selected value of parameter 1.1.1.1.7.2 is ‘Y’ |
|
|
Can be repeated |
N Use this ability if you have more than one document |
|
Data presentation |
Characterstring allows the previous [N.N] which ensures the backward compatibility |
|
Explanation on data presentation: |
|
|
|
The reference of the document defining the limit shall be provided in the characterstring and the document send to the Agency by the NRE.
Acceleration shall be presented with precision of 0.1 m/s2.
If there is no national rules or |
|
Explanation |
The document itself has to be upload by the NRE via the “reference document management” functionality. The reference of the document is provided for the parameter using the characterstring format. |
|
|
|
|
Number |
1.1.1.1.7.4 |
|
Title |
Existence of trackside hot axle box detector (HABD) |
|
XML Name |
SOL Track Parameter IHS_HABDExist |
|
Definition |
Existence of trackside HABD |
|
Applicable |
Y/NYA |
|
Can be repeated |
N |
|
Data presentation |
Single selection from the predefined list: Y/N |
|
General explanations |
|
|
Reference |
|
|
Validation |
|
|
|
|
|
|
|
|
Number |
1.1.1.1.7.5 |
|
Title |
Trackside HABD TSI compliant |
|
XML Name |
SOL Track Parameter IHS_TSIHABD |
|
Definition |
Specific for the French, Italian and Swedish networks. Trackside HABD compliant to TSI means that the HABD Trackside is compliant with: o EN 15437:2009 referred in TSIs (LOC&PAS 1302/2014, WAG 321/2013), o Specific cases mentioned in TSIs (LOC&PAS TSI 1302/2014, WAG 321/2013). |
|
Applicable |
Y/N/NYA |
|
Can be repeated |
N |
|
Data presentation |
Single selection from the predefined list: Y/N |
|
General explanations |
|
|
Reference |
|
|
Validation |
|
|
|
|
|
|
|
|
Number |
1.1.1.1.7.6 |
|
Title |
Identification of trackside HABD |
|
XML Name |
SOL Track Parameter IHS_HABDID |
|
Definition |
Specific for the French, Italian and Swedish networks. Applicable if trackside HABD is not TSI compliant, identification of trackside hot axle box detector. |
|
Applicable |
Y/N/NYA Y if the answer to parameter 1.1.1.1.7.5 is N |
|
Can be repeated |
N |
|
Data presentation |
Characterstring |
|
General explanations |
|
|
Reference |
|
|
Validation |
|
|
|
|
|
|
|
|
Number |
1.1.1.1.7.7 |
|
Title |
Generation of trackside HABD |
|
XML Name |
SOL Track Parameter IHS_HABDGen |
|
Definition |
Specific for the French Italian and Swedish networks. Generation of trackside hot axle box detector. |
|
Applicable |
Y/N/NYA “Y” if the answer to parameter 1.1.1.1.7.5 is “N” |
|
Can be repeated |
N |
|
Data presentation |
Single selection from the predefined list: Waiting provision of possible answers by the French, Italian and Swedish NREs |
|
General explanations |
|
|
Reference |
|
|
Validation |
|
|
|
|
|
|
|
|
Number |
1.1.1.1.7.8 |
|
Title |
Railway location of trackside HABD |
|
XML Name |
SOL Track Parameter IHS_HABDLoc |
|
Definition |
Specific for the French Italian and Swedish networks. Applicable if trackside HABD is not TSI compliant, localisation of trackside hot axle box detector. |
|
Explanation on Definition |
The railway location identifies the location of the HADB in the system of reference of the line to which the track belongs |
|
Applicable |
Y/N/NYA “Y” if the answer to parameter 1.1.1.1.7.5 is “N” |
|
Can be repeated |
Y |
|
Data presentation |
Predefined CharacterString: [±NNNN.NNN] |
|
General explanations |
Explanation on data presentation: The location (generally the distance from the origin of the line to the centre) on a line is given in kilometres with decimals (precision of 0.001). The aim of the "CharacterString" at the end of the format has to precise the name or number of the line. Contrary to the regulation, the reference to the line is not needed: the parameter is still attached to the track of the line. The aim of the "CharacterString" at the end of the format has to precise the name or number of the line. |
|
Reference |
|
|
Validation |
|
|
|
|
|
Number |
1.1.1.1.7.9 |
|
Title |
Direction of measurement of trackside HABD |
|
XML Name |
SOL Track Parameter IHS_HABDDirecton |
|
Definition |
Direction of measurement of trackside HABD (Specific for the French Italian and Swedish networks) |
|
Applicable |
Y/N/NYA “Y” if the answer to parameter 1.1.1.1.7.5 is “N” |
|
Can be repeated |
N |
|
Data presentation |
Single selection from the predefined list: N/O/B |
|
explanations |
Specific for the French Italian and Swedish networks. Applicable if trackside HABD is not TSI compliant, direction of measurement of trackside hot axle box detector. If the direction of measurement is: |
|
|
|
|
General explanations |
|
|
Reference |
|
|
Validation |
|
|
|
|
|
|
|
|
Number |
1.1.1.1.7.10 |
|
Title |
Steady red lights required |
|
XML Name |
SOL Track Parameter IHS_RedLights |
|
Definition |
Sections where two steady red lights are required in accordance with Implementing Regulation (EU) 2019/773 |
|
Applicable |
Y/N/NYA |
|
Can be repeated |
N |
|
Data presentation |
Single selection from the predefined list: Y/N |
|
General explanations |
Regulation (EU) 2019/773 says: Specific case: Belgium, France, Italy, Portugal, Spain and UK may continue to apply notified national rules that require freight trains to be equipped with 2 steady red lights as a condition to run on sections of their network, where this is justified by operating practices already in place and/or national rules notified before end of January 2019. Cooperation with neighbouring countries: In the meantime Member States concerned, in particular at the request of the railway undertakings, shall perform an assessment with a view to accept the use of 2 reflective plates in one or more sections of their network if the result of the assessment is positive and define appropriate conditions, which shall be based upon an assessment of the risks and operational requirements. This assessment shall be completed within a maximum period of 6 months after receiving the railway undertaking's request. The acceptance of reflective plates shall be granted, unless the Member State can duly justify the refusal based on the negative result of the assessment. Member States shall in particular endeavour to permit the use of reflective plates on rail freight corridors, with a view to prioritise the current bottlenecks. These sections and details of any conditions pertaining to them shall be recorded in the RINF. Until the information is encoded in RINF, the infrastructure manager shall ensure the information is communicated to railway undertakings by other appropriate means. The infrastructure manager shall identify the sections of lines on which 2 steady red lights are required in the RINF. |
|
Reference |
art 4.2.2.1.3.2. of Implementing Regulation (EU) 2019/773 “Freight trains” |
the same as the direction defined by the start and end of the SoL: (N)
the opposite to the direction defined by the start and end of the SoL: (O)
both directions: (B)
|
|
|
|
Validation |
|
|
|
|
|
Number |
1.1.1.1.7.11 |
|
Title |
Belonging to a quieter route |
|
XML Name |
SOL Track Parameter IHS_QuietRoute |
|
Definition |
Belonging to a “quieter route” in accordance with Article 5b of Regulation (EU) 1304/2014. |
|
Applicable |
Y/NYA |
|
Can be repeated |
N |
|
Data presentation |
Single selection from the predefined list: Y/N |
|
General explanations |
Art 5B: A ‘quieter route’ means a part of the railway infrastructure with a minimum length of 20 km on which the average number of daily operated freight trains during the night-time as defined in national legislation transposing Directive 2002/49/EC of the European Parliament and of the Council (5) was higher than 12. The freight traffic in the years 2015, 2016 and 2017 shall be the basis for the calculation of that average number. In case the freight traffic due to exceptional circumstances diverges in a given year from that average number by more than 25 %, the Member State concerned can calculate the average number on the basis of the remaining two years Art 5.C 1: Member States shall designate quieter routes in accordance with Article 5b and the procedure set out in Appendix D.1 of the Annex. They shall provide the European Union Agency for Railways (‘the Agency’) with a list of quieter routes six months after the date of publication of this Regulation at the latest. The Agency shall publish those lists on its website. |
|
Reference |
Art 5b of Regulation (EU) 1304/2014 (amended by Regulation (EU) 2019/774) of 16 May 2019 |
|
|
|
|
Number |
1.1.1.1.8 |
|
Title |
Tunnel |
|
XML Name |
SOLTunnel |
|
Applicable |
Parameters of this group (from 1.1.1.1.8.1 to 1.1.1.1.8.11) are only applicable if tunnels exist on the SoL |
|
Can be repeated |
Y |
|
|
|
|
Number |
1.1.1.1.8.1 |
|
Title |
IM’s Code |
|
XML Name |
SOLTunnelIMCode |
|
Definition |
Infrastructure Manager means any body or undertaking that is responsible in particular for establishing and maintaining railway infrastructure or a part thereof. |
|
Applicable |
Y |
|
Can be repeated |
N |
|
Data presentation |
[AAAA] |
|
General explanations |
The Code is a unique identifier for the Infrastructure Manager and it shall be verified on national level. Each Section of Line may concern only one IM. |
|
Reference |
Article 3 (2) of Directive 2012/34/EU |
|
Validation |
No verification by RINF application. Check of the link between MS and IM’ Name must be done nationally. |
|
|
|
|
Number |
1.1.1.1.8.2 |
|
Title |
Tunnel identification |
|
XML Name |
SOLTunnelIdentification |
|
Definition |
Unique tunnel identification or unique number within Member State |
|
Applicable |
Y |
|
Can be repeated |
N |
|
Data presentation |
CharacterString. |
|
Comments |
Here should be given the name, number, code or any other expression which is normally used for the identification of the tunnel other than mentioned in parameters 1.1.1.1.8.3 – 1.1.1.1.8.4. In case when tunnel does not have its own identification within the Member State, the IM should deliver it himself. |
If the IM is subject to TAF/TAP TSIs, it corresponds to the code used in TAF/TAP TSIs.
In other cases, it corresponds to the "organisation code” assigned by the Agency for the specific needs of the RINF
|
Number |
1.1.1.1.8.3 |
|
Title |
Start of tunnel |
|
XML Name |
SOLTunnelStart |
|
Definition |
Geographical coordinates in decimal degrees and km of the line at the beginning of a tunnel. |
|
Applicable |
Y |
|
Can be repeated |
N |
|
Data presentation |
Predefined CharacterString: [Latitude (NN.NNNNNNN) + Longitude (±NN.NNNNNNN) + km (±NNNN.NNN)] |
|
General Explanations |
Geographical
coordinates according to the standard World Geodetic System (WGS). Precision for
both geographical latitude and geographical longitude is assumed as [NN.NNNNNNN] in
degrees with decimals what gives discretion of 10 Kilometre shall concern the national line identification given in 1.1.0.0.0.2 Location of the point which is assumed to be the beginning of the tunnel it is the point on the track centre line where is laid the vertical shadow of the extreme part of the tunnel’s portal. Data collected in the UK in miles will be transformed to km before uploading to the RINF application. |
|
XML example |
<SOLTunnelStart Latitude="51.5479123" Longitude="-0.076732" Kilometer="0.270"/> |
|
|
|
|
Number |
1.1.1.1.8.4 |
|
Title |
End of tunnel |
|
XML Name |
SOLTunnelEnd |
|
Definition |
Geographical coordinates in decimal degrees and km of the line at the end of a tunnel. |
|
Applicable |
Y |
|
Can be repeated |
N |
|
Data presentation |
Predefined CharacterString: [Latitude (NN.NNNNNNN) + Longitude (±NN.NNNNNNN) + km (±NNNN.NNN)] |
|
General Explanations |
Geographical
coordinates according to the standard World Geodetic System (WGS). Precision for
both geographical latitude and geographical longitude is assumed as [NN.NNNNNNN] in
degrees with decimals what gives discretion of 10 Location of the point which is assumed to be the end of the tunnel it is the point on the track centre line where is laid the vertical shadow of the extreme part of the tunnel’s portal. Data collected in the UK in miles will be transformed to km before uploading to the RINF application. |
|
Example |
<SOLTunnelEnd Latitude="51.5479123" Longitude="-0.076732" Kilometer="0.270"/> |
|
|
|
|
Number |
1.1.1.1.8.5 |
|
Title |
EC declaration of verification for tunnel (SRT) |
|
XML Name |
SOL Tunnel Parameter ITU_ECVerification |
|
Definition |
Unique number for EC declarations following format requirements specified in the ‘Document about practical arrangements for transmitting interoperability documents’ |
|
Explanation on Definition |
(SRT) in title means that here we include only declarations concerning requirements of SRT TSI for infrastructure system on the specific track. Parameter shall be repeated when different EC declarations were issued for different elements of infrastructure subsystem on the specific track in the tunnel. |
|
Applicable |
Y/N/NYA |
|
Explanation on applicability: “Y” shall be selected in case when EC declaration was issued |
|
|
Can be repeated |
Y |
|
Data presentation |
Predefined CharacterString: [CC/RRRRRRRRRRRRRR/YYYY/NNNNNN] |
|
General Explanations |
With the extension of scope according to Interoperability Directive 2008/57/EC, geographical scope of the INF, ENE and CCS TSIs now includes all the networks (TEN and off-TEN) with the following nominal track gauges: 1435, 1520, 1524, 1600 and 1668 mm |
|
Reference concerning format |
‘Document about practical arrangements for transmitting interoperability documents' [23] |
|
Validation |
The validation is described before this Table, in section 2.3. |
|
|
|
|
Number |
1.1.1.1.8.6 |
|
Title |
EI declaration of demonstration for tunnel (SRT) |
|
XML Name |
SOL Tunnel Parameter ITU_EIDemonstration |
|
Definition |
Unique number for EI declarations following the same format requirements as specified in the ‘Document about practical arrangements for transmitting interoperability documents’ |
|
Explanation on Definition |
(SRT) in title means that here we include only declarations concerning requirements of SRT TSI for infrastructure system on the specific track. Parameter shall be repeated when different EI declarations were issued for different elements of infrastructure subsystem on the specific track in the tunnel. |
|
Can be repeated |
Y |
|
Explanation on repeatability: It may happen that several EI declarations were issued – then parameter has to be repeated as many times as many declarations were issued. |
|
|
Applicable |
Y/N/NYA |
|
Explanation on applicability: “Y” shall be selected in case when the demonstration was executed and EI declaration was issued |
|
|
Data presentation |
Predefined CharacterString: [CC/RRRRRRRRRRRRRR/YYYY/NNNNNN]) |
|
General Explanations |
It may happen that several EI declarations were issued – then parameter has to be repeated as many times as many declarations were issued. The procedure for demonstration that existing network fits to requirements of the TSIs is executed on voluntary bases, so when EI declaration do not exist then the parameter is optional. |
|
References |
documents' |
|
Validation |
The validation is described before this Table, in section 2.3. |
|
|
|
Recommendation 2014/881/EU
‘Document about practical arrangements for transmitting interoperability
|
Number |
1.1.1.1.8.7 |
|
Title |
Length of tunnel |
|
XML Name |
SOL Tunnel Parameter ITU_Length |
|
Definition |
Length of a tunnel in metres from entrance portal to exit portal. |
|
Applicable |
Y/NYA |
|
Y only for a tunnel with length of 100 metres or more. |
|
|
Can be repeated |
N |
|
Data presentation |
[NNNNN] |
|
|
Explanation on data presentation: Length of a tunnel in metres from portal to portal at the level of the top of rail. |
|
Validation |
As the validation, whether the parameter is mandatory cannot be performed by the RINF application, the validation has to be done by the NRE. |
|
|
|
|
Number |
1.1.1.1.8.8 |
|
Title |
Cross section area |
|
XML Name |
SOL Tunnel Parameter ITU_CrossSectionArea |
|
Definition |
Smallest cross section area in square metres of the tunnel |
|
Applicable |
Y/N/NYA Y if the speed of the line is equal or greater than 200km/h Reference: 4.2.10.1 of INF TSI on Maximum pressure variations in tunnels |
|
Can be repeated |
N |
|
Data presentation |
[NNN] |
|
Explanation on data presentation: Smallest real cross section area (expressed in square metres) of the tunnel. |
|
|
|
|
|
Number |
1.1.1.1.8.8.1 |
|
Title |
compliance of the tunnel with INF TSI |
|
XML Name |
SOL Tunnel Parameter ITU_TSITunnel |
|
Definition |
compliance of the tunnel with INF TSI at the maximum permitted speed |
|
Applicable |
Y/N/NYA Y if the speed of the line is equal or greater than 200km/h |
|
Can be repeated |
N |
|
Data presentation |
Single selection from the predefined list: Y/N |
|
Explanation on data presentation: |
|
|
Reference |
clause 4.2.10.1 of INF TSI on Maximum pressure variations in tunnels |
|
|
|
|
Number |
1.1.1.1.8.8;2 |
|
Title |
Document available from the IM with precise description of the tunnel |
|
XML Name |
SOL Tunnel Parameter ITU_TunnelDocRef |
|
Definition |
Electronic document available from the IM stored by the Agency with precise description of the clearance gauge and geometry of the tunnel |
|
Applicable |
Y/N/NYA |
|
Can be repeated |
Y |
|
Data presentation |
Characterstring |
|
Explanation |
The document itself has to be upload by the NRE via the “reference document management” functionality. The reference of the document is provided for the parameter using the characterstring format. |
|
Number |
1.1.1.1.8.9 |
|
Title |
Existence of emergency plan |
|
XML Name |
SOL Tunnel Parameter ITU_EmergencyPlan |
|
Definition |
Indication whether emergency plan exists. |
|
Applicable |
Y/N/NYA |
|
Explanation on applicability: Y for tunnels longer than 1 km, in accordance with section 4.4.2 of SRT TSI, the emergency plan is mandatory only for tunnel length of more than 1km. ‘N’=not applicable can be selected for short tunnels of less than 1 km, as for them the fire category according SRT TSI does not exist. |
|
|
Can be repeated |
N |
|
Data presentation |
Single selection from the predefined list: Y N |
|
General Explanations |
Emergency plan has to be a document developed for each tunnel under the direction of the IM, in co-operation, where appropriate, with RUs, Rescue services and relevant authorities. It shall be consistent with the self-rescue, evacuation and rescue facilities provided. |
|
References |
SRT TSI: 4.4.2 OPE TSI: 4.2.3.7 |
|
|
|
|
Number |
1.1.1.1.8.10 |
|
Title |
Fire category of rolling stock required |
|
XML Name |
SOL Tunnel Parameter ITU_FireCatReq |
|
Definition |
Categorisation on how a passenger train with a fire on board will continue to operate for a defined time period |
|
|
Y/N/NYA |
|
Explanation on applicability: ‘N’=not applicable shall be selected for short tunnels of less than 1 km, as for them the fire category according SRT TSI does not exist. |
|
|
Can be repeated |
N |
|
Data presentation |
Single selection from the predefined list: A B none |
|
Explanation on data presentation: Wherever category B is not needed, generally the category A has to be understood as the default value. ‘None’ shall be selected when none of A or B fire category is applied for a specific tunnel. |
|
|
References |
SRT TSI: 1.1.3 LOC&PAS TSI: 4.2.10.1 |
|
|
|
|
Number |
1.1.1.1.8.11 |
|
Title |
National fire category of rolling stock required |
|
XML Name |
SOL Tunnel Parameter ITU_NatFireCatReq |
|
Definition |
Categorisation on how a passenger train with a fire on board will continue to operate for a defined time period - according to national rules if they exist. |
|
Can be repeated |
N |
|
Applicable |
Y/N/NYA |
|
Explanation on applicability: ‘Y’ only for tunnels when for the parameter 1.1.1.1.8.10 the option ‘none’ was selected and national rules are existing. ‘N’=not applicable shall be selected when respective national rules do not exist |
|
|
Data presentation |
CharacterString |
|
Explanation on data presentation: Data shall include both the category and brief name of the document introducing the categorisation |
|
|
|
|
|
Number |
1.1.1.2 |
|
Title |
Energy subsystem |
|
Can be repeated |
N |
|
|
|
|
Number |
1.1.1.2.1 |
|
Title |
Declarations of verification for track |
|
XML Name |
EDE |
|
Can be repeated |
N |
|
|
|
|
Number |
1.1.1.2.1.1 |
|
Title |
EC declaration of verification for track (ENE) |
|
XML Name |
SOL Track Parameter EDE_ECVerification |
|
Definition |
Unique number for EC declarations following format requirements specified in the ‘Document about practical arrangements for transmitting interoperability documents’ |
|
Explanation on Definition |
(ENE) in title means that here we include only declarations concerning energy subsystem on the specific track. |
|
Applicable |
Y/N/NYA |
|
Explanation on applicability: “Y” shall be selected in case when EC declaration was issued |
|
|
Can be repeated |
Y |
|
Explanation on repeatability: Parameter shall be repeated when different EC declarations were issued for different elements of energy subsystem on the specific track. |
|
|
Data presentation |
Predefined CharacterString: [CC/RRRRRRRRRRRRRR/YYYY/NNNNNN] |
|
General Explanations |
The required value is the number of the EC declaration presented in format defined for ERADIS. With the extension of scope according to Interoperability Directive 2008/57/EC, geographical scope of the ENE TSI now includes all the networks (TEN and off-TEN) with the following nominal track gauges: 1435, 1520, 1524, 1600 and 1668 mm |
|
Reference concerning format |
‘Document about practical arrangements for transmitting interoperability documents' [23] |
|
Validation |
The validation is described before this Table, in section 2.3. |
|
|
|
|
Number |
1.1.1.2.1.2 |
|
Title |
EI declaration of demonstration for track (ENE) |
|
XML Name |
SOL Track Parameter EDE_EIDemonstration |
|
Definition |
Unique number for EI declarations following the same format requirements as specified in the ‘Document about practical arrangements for transmitting interoperability documents’. |
|
Explanation on Definition |
(ENE) in title means that here we include only declarations concerning energy subsystem on the specific track. |
|
Applicable |
Y/N/NYA |
|
Explanation on applicability: “Y” shall be selected in case when the demonstration was executed and EI declaration was issued |
|
|
Can be repeated |
Y |
|
Explanation on repeatability: Parameter shall be repeated when different EI declarations were issued for different elements of energy subsystem on the specific track. |
|
|
Data presentation |
Predefined CharacterString: [CC/RRRRRRRRRRRRRR/YYYY/NNNNNN]) |
|
General Explanations |
It may happen that several EI declarations were issued – then parameter has to be repeated as many times as many declarations were issued. The procedure for demonstration that existing network fits to requirements of the TSIs is executed on voluntary bases, so when EI declaration do not exist then the parameter is optional. If EI declaration was not issued, then field shall be left empty. |
|
References |
documents' |
|
Validation |
The validation is described before this Table, in section 2.3. |
|
|
|
Recommendation 2014/881/EU
‘Document about practical arrangements for transmitting interoperability
|
Number |
1.1.1.2.2 |
|
Title |
Contact line system |
|
XML Name |
ECS |
|
Can be repeated |
N |
|
|
|
|
Number |
1.1.1.2.2.1.1 |
|
Title |
Type of contact line system |
|
XML Name |
SOL Track Parameter ECS_SystemType |
|
Definition |
Indication of the type of the contact line system. |
|
Applicable |
Y/NYA |
|
Can be repeated |
Y If this parameter is repeated, parameters 1.1.1.2.2.1.2, and 1.1.1.2.2.2 shall be created also for the corresponding type. These two parameters are to be considered children of the current. For grouping “children” parameters of the current parameter, an XML attribute called “Set” must be declared at the parent and children levels with the same keyword value. Modification already accepted from the paragraph above |
|
If this parameter is repeated, parameters 1.1.1.2.2.1.2 , and 1.1.1.2.2.2 shall be
created also for the corresponding type. These two parameters are to be considered
children of the current. For grouping “children” parameters of the current
parameter, an XML attribute called “set” must be declared at the parent and children
levels with the same If this parameter is repeated, parameters 1.1.1.2.2.1.2, 1.1.1.2.2.2, 1.1.1.2.2.4 and 1.1.1.2.5.1 shall be created also for the corresponding type. These four parameters are to be considered children of the current. For grouping “children” parameters of the current parameter, an XML attribute called “set” must be declared at the parent and children levels with the same keyword value. |
|
|
Data presentation |
Single selection from the predefined list: Overhead contact line (OCL) Third Rail Fourth Rail Not electrified |
|
Comments |
When the value "not electrified" is chosen, all parameters 1.1.1.2.2.1.2 - 1.1.1.2.5.3 are not applicable. When the value “Third Rail” or “Fourth Rail” is chosen, parameters 1.1.1.2.2.3, 1.1.1.2.2.5 - 1.1.1.2.4.2.3, 1.1.1.2.5.2 and 1.1.1.2.5.3 are not applicable |
|
|
|
|
Number |
1.1.1.2.2.1.2 |
|
Title |
Energy supply system (Voltage and frequency) |
|
XML Name |
SOL Track Parameter ECS_VoltFreq |
|
Definition |
Indication of the traction supply system (nominal voltage and frequency) |
|
Applicable |
Y/N/NYA |
|
Explanation on applicability: When "not electrified" is chosen in parameter 1.1.1.2.2.1.1, then this parameter is not applicable. |
|
|
Can be repeated |
Y An XML attribute called “Set” will be used to link the value of this parameter to the parameter 1.1.1.2.2.1.1 / ECS_SystemType |
|
Data presentation |
Single selection from the predefined list: AC 25kV-50Hz AC 15kV-16.7Hz DC 3kV DC 1.5kV DC (Specific Case FR) DC 750V DC 650V DC 600V DC 850V other |
|
Explanation on data presentation: If the real values exceed range of the EN 50163:2004, then option ‘other’ shall be selected. |
|
|
References |
ENE TSI: 4.2.3 EN 50163:2004: clause 4 |
|
|
|
|
|
|
|
Number |
1.1.1.2.2.1.2.1 |
|
Title |
Energy supply system TSI compliant |
|
XML Name |
SOL Track Parameter ECS_TSIVoltFreq |
|
Definition |
indication if the traction supply system (nominal voltage and frequency) is fully compliant with TSI |
|
Applicable |
Y/N/NYA |
|
Explanation on applicability: When "not electrified" is chosen in parameter 1.1.1.2.2.1.1, then this parameter is not applicable. |
|
|
Can be repeated |
Y An XML attribute called “Set” will be used to link the value of this parameter to the parameter 1.1.1.2.2.1.1 / ECS_SystemType |
|
Data presentation |
Single selection from the predefined list: |
|
|
Y N |
|
Explanation on data presentation: |
|
|
References |
This parameter is identified in appendix D1 of OPE TSI as being checked for route compatibility. But it is not of the corresponding list of the RINF Regulation as published. The parameter stays not mandatory. The validation process will not request an xml line. But as it is in the annex D1 of the OPE TSI, any railway undertaking can legitimately ask the IM to provide him the information. |
|
|
|
|
Number |
1.1.1.2.2.1.3 |
|
Title |
Umax2 for lines referred to in sections 7.4.2.2.1 and 7.4.2.11.1 of Regulation (EU) 1301/2014. |
|
XML Name |
SOL Track Parameter ECS_Umax2 |
|
Definition |
Specific for the French network Highest non-permanent voltage according to EN50163 for the lines referred to in point 7.4.2.2.1 and 7.4.2.11.1 of Regulation (EU) 1301/2014. |
|
Applicable |
Y/N/NYA |
|
Explanation on applicability: When "not electrified" is chosen in parameter 1.1.1.2.2.1.1, then this parameter is not applicable. |
|
|
Can be repeated |
Y An XML attribute called “Set” will be used to link the value of this parameter to the parameter 1.1.1.2.2.1.1 / ECS_SystemType |
|
Data presentation |
[NNNNNN] |
|
Explanation on data presentation: |
|
|
References |
|
|
Number |
1.1.1.2.2.2 |
|
Title |
Maximum train current |
|
XML Name |
SOL Track Parameter ECS_MaxTrainCurrent |
|
Definition |
Indication of the maximum allowable train current expressed in amperes. |
|
Explanation on Definition |
Maximum current taken by the complete train (composition of one or more units). The value shall be given in amperes. |
|
Applicable |
Y/N/NYA |
|
Explanation on applicability: When "not electrified" is chosen in parameter 1.1.1.2.2.1.1, then this parameter is not applicable. |
|
|
Can be repeated |
Y depending to the energy supply system (see 1.1.1.2.2.1.2) , SOL Track Parameter ECS_MaxTrainCurrent will be provided for each of selected voltage frequency An XML attribute called “Set” will be used to link the value of this parameter to the parameter 1.1.1.2.2.1.1 / ECS_SystemType and to the parameter 1.1.1.2.2.1.2 / ECS_VoltFreq |
|
Data presentation |
[NNNN] |
|
Reference |
ENE TSI: 4.2.4.1 |
|
|
|
|
Number |
1.1.1.2.2.3 |
|
Title |
Maximum current at standstill per pantograph |
|
XML Name |
SOL Track Parameter ECS_MaxStandstillCurrent |
|
Definition |
Indication of the maximum allowable train current at standstill for DC systems expressed in amperes. |
|
Explanation on Definition |
Parameter related to current taken by the vehicle when it is not in a traction or regenerative mode, e.g. preheating, air-condition, etc. |
|
Applicable |
Y/N/NYA |
|
Explanation on applicability: This parameter is applicable (“Y”) only if “Overhead contact line (OCL)” is selected for parameter 1.1.1.2.2.1.1 and if DC system is selected in 1.1.1.2.2.1.2 |
|
|
Can be repeated |
Y An XML attribute called “Set” will be used to link the value of this parameter to the parameter 1.1.1.2.2.1.1 / ECS_SystemType and to the parameter 1.1.1.2.2.1.2 / ECS_VoltFreq |
|
Data presentation |
[NNN] |
|
References |
ENE TSI: 4.2.5, LOC&PAS TSI: 4.2.8.2.5 |
|
|
|
|
Number |
1.1.1.2.2.4 |
|
Title |
Permission for regenerative braking |
|
XML Name |
SOL Track Parameter ECS_RegenerativeBraking |
|
Definition |
Indication whether regenerative braking is permitted or not. |
|
Applicable |
Y/N/NYA |
|
Explanation on applicability: When "not electrified" is chosen in parameter 1.1.1.2.2.1.1, then this parameter is not applicable |
|
|
Can be repeated |
Y An XML attribute called “Set” will be used to link the value of this parameter to the parameter 1.1.1.2.2.1.1 / ECS_SystemType |
|
Data presentation |
Single selection from the predefined list: Y N “allowed under conditions” |
|
Explanation on data presentation: When regenerative braking is permitted (also when under conditions) – then shall be selected ‘yes’, when it is not permitted – then shall be selected ‘no’. |
|
|
|
|
|
Number |
1.1.1.2.2.5 |
|
Title |
Maximum contact wire height |
|
XML Name |
SOL Track Parameter ECS_MaxWireHeight |
|
Definition |
Indication of the maximum contact wire height expressed in metres. |
|
Applicable |
Y/N/NYA |
|
Explanation on applicability: This parameter is applicable (“Y”) only if “Overhead contact line (OCL)” is selected in 1.1.1.2.2.1.1 |
|
|
Can be repeated |
N |
|
Data presentation |
[N.NN] |
|
Explanation on data presentation: The value given can be design value or the last known measured value. If there is no change in height, nominal value will be given. Values shall be given in metres with precision of 0.01 m. |
|
|
|
|
|
Number |
1.1.1.2.2.6 |
|
Title |
Minimum contact wire height |
|
XML Name |
SOL Track Parameter ECS_MinWireHeight |
|
Definition |
Indication of the minimum contact wire height expressed in metres. |
|
Applicable |
Y/N/NYA |
|
Explanation on applicability: This parameter is applicable (“Y”) only if “Overhead contact line (OCL)” is selected in 1.1.1.2.2.1.1 |
|
|
Can be repeated |
N |
|
Data presentation |
[N.NN] |
|
Explanation on data presentation: The value given can be design value or the last known measured value. If there is no change in height, nominal value will be given. Values shall be given in metres with precision of 0.01 m. |
|
|
|
|
|
Number |
1.1.1.2.3 |
|
Title |
Pantograph |
|
XML Name |
EPA |
|
Can be repeated |
N |
|
|
|
|
Number |
1.1.1.2.3.1 |
|
Title |
Accepted TSI compliant pantograph heads |
|
XML Name |
SOL Track Parameter EPA_TSIHeads |
|
Definition |
Indication of which TSI compliant pantograph heads are allowed to be used. |
|
Applicable |
Y/N/NYA |
|
Explanation on applicability: This parameter is applicable (“Y”) only if “Overhead contact line (OCL)” is selected for 1.1.1.2.2.1.1, It is not applicable (“N") if there is no contact line. |
|
|
Can be repeated |
Y |
|
Data presentation |
Single selection from the predefined list: 1950 mm (Type 1) 1950 mm (Type 1) with insulated horns. 1600 mm (EP) 2000 mm – 2260 mm none |
|
Explanation on data presentation: The parameter can contain more than one pantograph defined in LOC&PAS TSI. Presentation of those pantographs is done by repetition of the parameter with a single selection. If declaring acceptance of pantograph heads 1950 (type 1), both insulated and conductive horns shall be accepted. |
|
|
References |
LOC&PAS TSI: 4.2.8.2.9.2 |
|
|
EN 50367 (2012): Annex A.2 and EN 50206-1 (2010): 4.2 and 6.2.3 |
|
|
|
|
Number |
1.1.1.2.3.2 |
|
Title |
Accepted other pantograph heads |
|
XML Name |
SOL Track Parameter EPA_OtherHeads |
|
Definition |
Indication of which pantograph heads are allowed to be used |
|
Applicable |
Y/N/NYA |
|
Explanation on applicability: This parameter is applicable (“Y”) only if “Overhead contact line (OCL)” is selected in 1.1.1.2.2.1.1 |
|
|
Can be repeated |
Y |
|
Explanation on repeatability: When more than one value of the parameter has to be published, then parameter has to be repeated as many times as many values of the parameter will be published. |
|
|
Data presentation |
Single selection from the predefined list: 1950 mm (Type2) 1950 mm (PL) 1800 mm (NO,SE) 1760 mm (BE) 1600 mm (GB,CTRL) 1600 mm (GB) 1450 mm other none |
|
Explanation on data presentation: The parameter may contain more than one type of the pantograph head – all of them shall be indicated by repetition of the parameter with different single selections. Option ‘other’ shall be selected for types of pantograph heads not specified in the predefined list. |
|
|
References |
LOC&PAS TSI: 7.3.2.14 (specific cases), EN 50367 (2012): Annex B |
|
|
|
|
Number |
1.1.1.2.3.3 |
|
Title |
Requirements for number of raised pantographs and spacing between them, at the given speed |
|
XML Name |
SOL Track Parameter EPA_NumRaisedSpeed |
|
Definition |
Indication of maximum number of raised pantographs per train allowed and minimum spacing centre line to centre line of adjacent pantograph heads, expressed in metres, at the given speed |
|
Applicable |
Y/N/NYA |
|
Explanation on applicability: This parameter is applicable (“Y”) only if “Overhead contact line (OCL)” is selected in 1.1.1.2.2.1.1 |
|
|
Can be repeated |
Y |
|
Data presentation |
Predefined CharacterString: [N] [NNN] [NNN] |
|
Explanation on data presentation: [N] is number of pantographs. First [NNN] is minimum distance between pantographs, in metres. Second [NNN] is the speed considered in km/h. Data collected in the UK in miles per hour will be transformed to km per hour before uploading to the RINF application. |
|
|
General Explanations |
This parameter gives the information about the number of pantographs and the distance between them at a given speed for which the Overhead Contact Line (OCL) has been designed. As for different speeds different combinations of number of pantographs and distance between them may exist, so this parameter can be repeated to present all of them. |
|
References |
ENE TSI: 4.2.13 ; LOC&PAS TSI: 4.2.8.2.9.7 |
|
|
|
|
Number |
1.1.1.2.3.4 |
|
Title |
Permitted contact strip material |
|
XML Name |
SOL Track Parameter EPA_StripMaterial |
|
Definition |
Indication of which contact strip materials are permitted to be used. |
|
Applicable |
Y/N/NYA |
|
Explanation on applicability: This parameter is applicable (“Y”) only if “Overhead contact line (OCL)” is selected in 1.1.1.2.2.1.1 |
|
|
Can be repeated |
Y |
|
Explanation on repeatability: When more than one value of the parameter has to be published, then parameter has to be repeated – as many times as many values of the parameter will be published. |
|
|
Data presentation |
Single selection from the predefined list: copper plain carbon copper steel copper alloy impregnated carbon ([NN] % of metallic content) carbon with additive material carbon with cladded copper sintered copper other |
|
Explanation on data presentation: [NN] for impregnated carbon concern the metallic content in %. In case of selection of this option, the respective value of the metallic content has to be added. [NN] is the maximum percentage allowed. In case of permitted material different than specified in predefined list, the option ‘other’ shall be selected. |
|
|
Reference |
LOC&PAS TSI: 4.2.8.2.9.4.2 |
|
|
|
|
Number |
1.1.1.2.4 |
|
Title |
OCL separation sections |
|
XML Name |
EOS |
|
Can be repeated |
N |
|
|
|
|
Number |
1.1.1.2.4.1.1 |
|
Title |
Phase separation |
|
XML Name |
SOL Track Parameter EOS_Phase |
|
Definition |
Indication of existence of phase separation and required information. |
|
Applicable |
Y/N/NYA |
|
Explanation on applicability: This parameter is applicable (“Y”) only if “Overhead contact line (OCL)” is selected in 1.1.1.2.2.1.1 |
|
|
Can be repeated |
N |
|
Data presentation |
Single selection from the predefined list Y N |
|
Explanation on data presentation: In case of existence of phase separation on the track or on the section of the line the option ‘Y’ shall be selected. |
|
|
|
|
|
Number |
1.1.1.2.4.1.2 |
|
Title |
Information on phase separation |
|
XML Name |
SOL Track Parameter EOS_InfoPhase |
|
Definition |
Indication of required several information on phase separation |
|
Applicable |
Y/N/NYA |
|
Explanation on applicability: Applicable when in parameter 1.1.1.2.4.1.1 selected option is ‘Y’ |
|
|
Can be repeated |
N Y |
|
Data presentation |
Predefined CharacterString: + distance type [MIN/MAX] + length [NNN] + switch off breaker [Y/N] + lower pantograph [Y/N] + change supply system [Y/N] + km [NNN.NNN] |
|
Explanation on data presentation: + distance type [MIN/MAX] - single selection of 'MIN=minimum' or 'MAX=maximum' to show whether the length is a minimum distance between the inner contact strips of the pantographs or a maximum distance between the outer contact strips of the pantographs. Multiple strings for this parameter are accepted + ‘length [NNN]’ – the length of the phase separation in metres + ‘switch off breaker [Y/N]’ – single selection of ‘Y=yes’ or ‘N=no’ to show whether the breaker has to be switched off + ‘lower pantograph [Y/N]’ – single selection of ‘Y=yes’ or ‘N=no’ to show whether the pantograph has to be lowered + ‘change supply system [Y/N]’ – single selection of Y=yes’ or ‘N=no’ to show if the energy supply system changes + Km [NNN.NNN] - the location from the start of the line where the new value is valid |
|
|
References |
ENE TSI: 4.2.15 |
|
|
|
|
Number |
1.1.1.2.4.2.1 |
|
Title |
System separation |
|
XML Name |
SOL Track Parameter EOS_System |
|
Definition |
Indication of existence of system separation |
|
Applicable |
Y/N/NYA |
|
Explanation on applicability: This parameter is applicable (“Y”) only if the value “Overhead contact line (OCL)” is selected for 1.1.1.2.2.1.1 |
|
|
Can be repeated |
N |
|
Data presentation |
Single selection from predefined list Y N |
|
Explanation on data presentation: In case of existence of system separation on the track or on the section of the line and required information on the section of the line, the option ‘Y=yes’ shall be selected. |
|
|
|
|
|
Number |
1.1.1.2.4.2.2 |
|
Title |
Information on system separation |
|
XML Name |
SOL Track Parameter EOS_InfoSystem |
|
Definition |
Indication of required several information on system separation |
|
Applicable |
Y/N/NYA |
|
Explanation on applicability: Selection ‘Y’=yes when in parameter 1.1.1.2.4.2.1 selected option is ‘Y’. |
|
|
Can be repeated |
N Y |
|
Data presentation |
Predefined CharacterString:
length [NNN] + switch off breaker [Y/N] + lower pantograph [Y/N] +[CharacterString]
+ km [NNN.NNN] |
|
Explanation on data presentation: + ‘length [NNN]’ – the length of the system separation in metres + ‘switch off breaker [Y/N]’ – single selection of ‘Y=yes’ or ‘N=no’ to show whether the breaker has to be switched off + ‘lower pantograph [Y/N]’ – single selection of ‘Y=yes’ or ‘N=no’ to show whether the pantograph has to be lowered +
[CharacterString] + Km [NNN.NNN] - the location from the start of the line where the new value is valid |
|
|
References |
ENE TSI: 4.2.16 |
|
|
|
|
|
|
|
Number |
1.1.1.2.4.3 |
|
Title |
Distance between signboard and phase separation ending |
|
XML Name |
SOL Track Parameter EOS_DistSignToPhaseEnd |
|
Definition |
Specific for route compatibility check on French network. Distance between the signboard authorizing the driver to “raise pantograph” or “close the circuit breaker” after passing the phase separation and the end of the phase separation section. |
|
Applicable |
Y/N/NYA |
|
Explanation on applicability: Specific for route compatibility check on French network. |
|
|
Can be repeated |
N |
|
Data presentation |
Predefined CharacterString: [NNN] |
|
Explanation on data presentation: The distance is expressed in meters |
|
|
References |
|
|
|
|
|
Number |
1.1.1.2.5 |
|
Title |
Requirements for rolling stock |
|
XML Name |
ERS |
|
Can be repeated |
N |
|
|
|
|
Number |
1.1.1.2.5.1 |
|
Title |
Current or power limitation on board required |
|
XML Name |
SOL Track Parameter ERS_PowerLimitOnBoard |
|
Definition |
Indication of whether an on board current or power limitation function on vehicles is required. |
|
Applicable |
Y/N/NYA |
|
Explanation on applicability: When "not electrified" is chosen in parameter 1.1.1.2.2.1.1, then this parameter is not applicable selection ‘N’. |
|
|
Can be repeated |
Y |
|
An XML attribute called “Set” will be used to link the value of this parameter to the parameter 1.1.1.2.2.1.1 / ECS_SystemType |
|
|
Data presentation |
Single selection from predefined list: Y N |
|
References |
LOC&PAS TSI: 4.2.8.2.4 |
|
|
|
|
Number |
1.1.1.2.5.2. |
|
Title |
Contact force permitted |
|
XML Name |
SOL Track Parameter ERS_ContactForce |
|
Definition |
Indication of contact force allowed expressed in newtons |
|
Applicable |
Y/N/NYA |
|
Explanation on applicability: This parameter is applicable (“Y”) only if the value “Overhead contact line (OCL)” is selected for 1.1.1.2.2.1.1 |
|
|
Can be repeated |
N |
|
Data presentation |
CharacterString |
|
Explanation on data presentation: The force is either given as: a value of the static force and of the maximum force expressed in newtons, or as a formula for function of the speed. |
|
|
Comments |
The formula of the function shall represent the curve describing the value of the contact force in relation to the speed. Static and maximum forces are given only for the maximum permitted line speed (see parameter number 1.1.1.1.2.5). |
|
References |
EN 50367:2012 Annex A |
|
|
|
|
Number |
1.1.1.2.5.3 |
|
Title |
Automatic dropping device required |
|
XML Name |
SOL Track Parameter ERS_AutoDropRequired |
|
Definition |
Indication of whether an automatic dropping device (ADD) required on the vehicle. |
|
|
Y/N/NYA |
|
Explanation on applicability: This parameter is applicable (“Y”) only if the value “Overhead contact line (OCL)” is selected for 1.1.1.2.2.1.1 |
|
|
Can be repeated |
N |
|
Data presentation |
Single selection from the predefined list: Y N |
|
Reference |
EN 50206-1:2010 |
|
|
|
|
Number |
1.1.1.3 |
|
Title |
Control-command and signalling subsystem |
|
Can be repeated |
N |
|
|
|
|
Number |
1.1.1.3.1 |
|
XML Name |
CDE |
|
Title |
Declarations of verification for track |
|
Can be repeated |
N |
|
|
|
|
Number |
1.1.1.3.1.1 |
|
Title |
EC declaration of verification for track (CCS) |
|
XML Name |
SOL Track Parameter CDE_ECVerification |
|
Definition |
Unique number for EC declarations following format requirements specified in the ‘Document about practical arrangements for transmitting interoperability documents’ |
|
Explanation on Definition |
(CCS) in title means that here we include only declarations concerning command – control and signalling subsystem on the specific track. |
|
Applicable |
Y/N/NYA |
|
Explanation on applicability: “Y” shall be selected in case when EC declaration was issued |
|
|
Can be repeated |
Y |
|
Explanation on repeatability: For the specific track the several EC declarations may be issued, so parameter has to repeated as many times as many numbers of declarations has to be presented. |
|
|
Data presentation |
Predefined CharacterString: [CC/RRRRRRRRRRRRRR/YYYY/NNNNNN] |
|
General Explanations |
With the extension of scope according to Interoperability Directive 2008/57/EC, geographical scope of the CCS TSI now includes all the networks (TEN and off-TEN) with the following nominal track gauges: 1435, 1520, 1524, 1600 and 1668 mm |
|
Reference concerning format |
‘Document about practical arrangements for transmitting interoperability documents' [23] |
|
Validation |
The validation is described before this Table, in section 2.3. |
|
|
|
|
Number |
1.1.1.3.2 |
|
Title |
TSI compliant train protection system (ETCS) |
|
XML Name |
CPE |
|
Can be repeated |
N |
|
|
|
|
Number |
1.1.1.3.2.1 |
|
Title |
ETCS level |
|
XML Name |
SOL Track Parameter CPE_Level |
|
Definition |
ERTMS / ETCS application level related to the track side equipment. |
|
Applicable |
Y/NYA |
|
Can be repeated |
Y If this parameter is repeated, parameter 1.1.1.3.2.2 shall be created also for the corresponding type. This parameter is to be considered children of the current. For grouping “children” parameters of the current parameter, an XML attribute called “Set” must be declared at the parent and childrent levels with the same keyword value. |
|
Data presentation |
Single selection from the predefined list: N 0 1 2 3 NTC |
|
|
Explanation on data presentation: The different ERTMS / ETCS application levels are a way to express the possible operating relationships between track and train. Level definitions are principally related to the track side equipment used, to the way the track side information reaches the on- board units and to which functions are processed in the track side and in the on-board equipment respectively. The ETCS value NTC is only relevant when the line is dual equipped with ETCS (i.e., balises are placed in the track) and Class B system, and both systems are in operation at the same time. In those cases, this parameter should be filled relevant ETCS Level and repeated with the value “NTC”. If the line is only equipped with Class B, this should be reflected in Parameter 1.1.1.3.5.3, and this parameter should be set to “N”. |
|
Validation |
If “N” (= no ETCS on the trackside) is chosen from the list, all other ETCS parameters (from 1.1.1.3.2.2 to 1.1.1.3.2.7) are not applicable. If ETCS is on the trackside (‘N’ is not selected), all other ETCS parameters (from 1.1.1.3.2.2 to 1.1.1.3.2.10) are applicable |
|
References |
CCS TSI: 2.3 |
|
Number |
1.1.1.3.2.2 |
|
Title |
ETCS baseline |
|
XML Name |
SOL Track Parameter CPE_Baseline |
|
Definition |
ETCS baseline installed lineside. |
|
Applicable |
Y/N/NYA |
|
Explanation on applicability: Not applicable (‘N’) when selected value for 1.1.1.3.2.1 is ‘N’. Only applicable when selected value for 1.1.1.3.2.1 is not ‘N’ |
|
Can be repeated |
Y: SOL Track Parameter CPE_Baseline will be provided for each of selected ETCS Level (SOL Track Parameter CPE_Level) An XML attribute called “Set” will be used to link the value of this parameter to the ETCS Level. |
|
Data presentation |
Single choice from the predefined list prebaseline 2 baseline 2 baseline 3 Maintenance release 1 baseline 3 release 2 |
|
Explanation on data presentation: Prebaseline 2 corresponds to older versions, e.g. “corridor 2007” |
|
|
Reference |
CCS TSI: Table A2 of Annex 1 of Decision 2012/696/EU CCS TSI: Tables A2.1, A2.2 and A2.3 of Annex A of Regulation (EU) 2016/919 |
|
|
|
|
Number |
1.1.1.3.2.3 |
|
Title |
ETCS infill necessary for line access |
|
XML Name |
SOL Track Parameter CPE_Infill |
|
Definition |
Indication whether infill is required to access the line for safety reasons. |
|
Explanation on definition |
Infill is the criterion for a vehicle to get access to the |
|
Applicable |
Y/N/NYA |
|
Explanation on applicability: Only applicable when selected value for 1.1.1.3.2.1 is ‘1’. |
|
|
Can be repeated |
N |
|
Data presentation |
Single selection from the predefined list: Y / N |
|
General Explanations |
As indicated in CCS TSI section 7.2.6 an ETCS Level 1 trackside application may require that the on-board is equipped with the corresponding in-fill data transmission (Euroloop or radio) if the release speed is set to zero for safety reasons. |
|
Reference |
CCS TSI: 7.2.6 and 4.2.3 |
|
|
|
|
Number |
1.1.1.3.2.4 |
|
Title |
ETCS infill installed line-side |
|
XML Name |
SOL Track Parameter CPE_InfillLineSide |
|
Definition |
Information about installed trackside equipment capable to transmit infill information by loop or GSM-R for level 1 installation. |
|
Applicable |
Y/N/NYA |
|
Explanation on applicability: Only applicable when selected value for 1.1.1.3.2.1 is ‘1’. |
|
|
Can be repeated |
N |
|
Data presentation |
Single choice from the predefined list: None Loop GSM-R radio infill Loop & GSM-R radio infill |
|
Reference |
CCS TSI: 4.2.2 |
|
|
|
|
Number |
1.1.1.3.2.5 |
|
Title |
ETCS national packet 44 application implemented |
|
XML Name |
SOL Track Parameter CPE_NatApplication |
|
Definition |
Indication whether data for national applications is transmitted between track and train. |
|
Applicable |
Y/N/NYA |
|
Explanation on applicability: Not applicable ‘N’ when selected value for 1.1.1.3.2.1 is ‘N’. Only applicable when selected value for 1.1.1.3.2.1 is not ‘N’ |
|
|
Can be repeated |
N |
|
Data presentation |
Single selection from the predefined list: Y / N |
|
General Explanations |
Packets 44 are the means to transmit data for national applications between train and track and vice versa, using the data transmission facilities included within the ETCS. NID_XUSER values managed by ERA in a document about ETCS variables available on ERA website. |
|
Reference |
CCS TSI: 6.3.4 |
|
|
|
|
Number |
1.1.1.3.2.6 |
|
Title |
Existence of operating restrictions or conditions |
|
XML Name |
SOL Track Parameter CPE_RestrictionsConditions |
|
Definition |
Indication whether restrictions or conditions due to partial compliance with the CCS TSI exist. |
|
Applicable |
Y/N/NYA |
|
Explanation on applicability: Not applicable ‘N’ when selected value for 1.1.1.3.2.1 is ‘N’. Only applicable when selected value for 1.1.1.3.2.1 is not ‘N’ |
|
|
Can be repeated |
N |
|
Data presentation |
Single selection from the predefined list: |
|
|
Y / N |
|
General explanations |
In case of Y, the RU have to contact the IM to be informed of these conditions. ertms_en#meeting6 |
|
Reference |
CCS TSI: 6.4 |
|
|
|
|
Number |
1.1.1.3.2.8 |
|
Title |
Train integrity confirmation from on-board necessary for line access |
|
XML Name |
SOL Track Parameter CPE_IntegrityConfirmation |
|
Definition |
Indication whether Train Integrity monitoring system (TIMS) is required to access the line for safety reasons. |
|
Applicable |
Y/N/NYA |
|
Explanation on applicability: Only applicable when selected value for 1.1.1.3.2.1 is ‘3” |
|
|
Can be repeated |
N |
|
Data presentation |
Single selection from the predefined list: Y / N |
|
General Explanations |
|
|
Reference |
|
|
|
|
|
Number |
1.1.1.3.2.9 |
|
Title |
ETCS system compatibility |
|
XML Name |
SOL Track Parameter CPE_SystemCompatibility |
|
Definition |
ETCS requirements used for demonstrating technical compatibility. |
|
Applicable |
Y/N/NYA |
|
Explanation on applicability: Only applicable when selected value for 1.1.1.3.2.1 is not ‘N’ |
|
|
Can be repeated |
Y Explanation on repeatability: The vehicles are considered compatible with the infrastructure regarding this parameter, if matches any of the values declared. In case the value “Not Defined” or “ESC-EU-0” is used, is not expected to have repetitions with additional values. |
|
Data presentation |
Single selection from the predefined list: Not Defined ESC-EU-0 |
|
|
ESC-SE-01-HiL2 ESC-SE-02-BoL2 ESC-SE-03-L3 ESC-SE-04-HiL2B3 ESC-SE-05-BoL2B3 ESC-NL-01 ESC-NL-02 ESC-NL-03 ESC-NL-04 ESC-NL-05 ESC-NL-06 ESC-NL-07 ESC-NL-08 ESC-NL-09 ESC-NL-10 ESC-NL-11 ESC-NL-12 ESC-NL-13 ESC-NL-14 ESC-NL-15 ESC-NL-16 ESC-NL-17 ESC-NL-18 ESC-NL-19 ESC-NL-20 ESC-NL-21 ESC-NL-22 ESC-NL-23 ESC-FR-01-LB ESC-FR-02-LB ESC-FR-03-LB ESC-FR-04-LB ESC-FR-05-LB ESC-FR-06-LB ESC-FR-07-SF ESC-FR-08-SF ESC-FR-09-SF ESC-FR-10-SF ESC-FR-11-SF ESC-FR-12-SF |
|
|
ESC-FR-13-SF ESC-FR-14-SF ESC-FR-15-SF ESC-FR-16-SF ESC-FR-17-SF ESC-FR-18-SF ESC-FR-19-SF ESC-FR-20-SF ESC-FR-21-SF ESC-FR-22-LB ESC-FR-23-LB ESC-FR-24-AA ESC-FR-25-AD ESC-FR-26-AE ESC-FR-27-LGVEE ESC-FR-28-LGVEE ESC-FR-29-LGVEE ESC-FR-30-LGVEE ESC-FR-31-LGVEE ESC-FR-32-LGVEE ESC-FR-33-SEA ESC-FR-34-SEA ESC-FR-35-BPL ESC-FR-36-BPL ESC-BE-02-L2FS ESC-BE-03-L1LS ESC-BE-01-L1FS ESC-BE-04-LGV3_4 ESC-IT-01-RFI-1.0_L2_AVp_RMNA_01 ESC-IT-02-RFI-1.0_L2_AVp_MIBO_01 ESC-IT-03-RFI-1.0_L2_AVp_BOFI_01 ESC-IT-04-RFI-1.0_L2_AVp_TOMI_01 ESC-IT-05-RFI-1.0_L2_AVp_TRBR_01 ESC-IT-06-RFI-1.0_L2_AVp_DD_01 ESC-IT-08-RFI-2.0_L1_Cs_DONO_01 ESC-IT-07-RFI-2.0_L1_Cs_ISDO_01 ESC-IT-09-RFI-2.0_L1_Cs_CHIASSO_01 ESC-IT-10-RFI-2.1_L2_Cs_NOPD_01 ESC-IT-11-RFI-2.0_L1_Cs_PTLU_01ESC-IT-12-RFI-2.0_L1_Cs_ISDO_CH_01 |
|
|
ESC-IT-13-RFI-2.0_L1_Cs_PTLU_CH_01 ESC-IT-14-RFI_2.1_L1_Cs_VENTIMIGLIA_01 ESC-IT-15-RFI_2.1_L1_Cs_VENTIMIGLIA_FR_01 ESC-IT-16-RFI_2.1_L1_Cs_VIVO_01 ESC-IT-17-RFI_2.1_L2_Cs_MIMOCH_01 ESC-IT-18-RFI_2.1_L2_Cs_NOPD_02 ESC-IT-19-RFI_1.0_L2_AVp_AGGR01_01 ESC-IT-20-RFI_1.0_L2_AVp_AGGR02_01 ESC-IT-21-RFI_2.0_L1_Cs_AGGR03_01 ESC-IT-23-RFI_2.1_L1_Cs_AGGR05_01 ESC-PL-01-L1 ESC-PL-02-L1LS ESC-PL-03-L2 ESC-PL-04-L2 ESC-PL-05-L2 ESC-PL-06-L2 ESC-NO-01 ESC-NO-02 ESC-DK-01-East ESC-DK-02-West ESC-AT-01 ESC-CZ-01 ESC-CZ-02 ESC-RO-01 ESC-DE-01-B2_L2 ESC-DE-02-B3_L2ESC-CH-01-L1LS ESC-CH-02-L2 ESC-CH-03-L1LSL2 ESC-LU-01-RFN ESC-LU-02-MSM |
|
General Explanations |
As defined in the revised CCS TSI in sections 6.1.2.4 and 6.1.2.5, the Agency will “set up and manage in a technical document the set of checks to demonstrate the technical compatibility of an on-board subsystem with the trackside subsystem”. The predefined list of values will follow the changes in that technical document. Each set of checks will have a unique id, like “ESC-1” (final format not defined). The different values to be defined inside each network need to be submitted by each IM with the support of their suppliers to the Agency. (CCS TSI 6.1.2.4 and 6.1.2.5 – Regulation (EU) 2019/776). The Agency will then compile them in a Technical Document, give them an identifier, and after, these identifiers will be available for selection in RINF and ERA TV. |
|
|
Therefore, these values will not be available until the IM has communicated the checks to the Agency. There is information about the ESC/RSC and the submission to the Agency in the ERA webpage (Link). More information will be included in the CCS TSI application guide. The deadline set in the CCS TSI for IMs to complete this process is 16 January 2020. |
|
Reference |
Agency Technical Document ESC/RSC (https://www.era.europa.eu/sites/default/files/activities/docs/era_td- 011rec1028_esc-rsc_technical_document_en.pdf). CCS TSI Regulation (EU) 2019/776 section 4.2.17 and 6.1.2.4 |
|
|
|
|
Number |
1.1.1.3.2.10 |
|
Title |
ETCS M_version |
|
XML Name |
SOL Track Parameter CPE_MVersion |
|
Definition |
ETCS M_version according to SRS 7.5.1.9 |
|
Applicable |
Y/N/NYA |
|
Explanation on applicability: Only
applicable when selected value for 1.1.1.3.2.1 is |
|
|
Can be repeated |
N |
|
Data presentation |
Single selection from the predefined list: 1.0 1.1 2.0 2.1 |
|
General Explanations |
|
|
Reference |
CCS TSI: ETCS M_version according to SRS 7.5.1.9 |
|
|
|
|
Number |
1.1.1.3.3 |
|
Title |
TSI compliant radio (GSM-R) |
|
XML Name |
CRG |
|
Can be repeated |
N |
|
|
|
|
Number |
1.1.1.3.3.1 |
|
Title |
GSM-R version |
|
XML Name |
. SOL Track Parameter CRG_Version |
|
Definition |
GSM-R version installed lineside |
|
Applicable |
Y/NYA |
|
Can be repeated |
Y |
|
Explanation on repeatability: When more than one value of the parameter has to be published, then parameter has to be repeated – as many times as many values of the parameter will be published. The |
|
|
|
parameter may be repeated if different versions are installed in different sections of the network. |
|
Data presentation |
Single selection from the predefined list: none previous version to Baseline 0 Baseline 0 r3 Baseline 0 r4 Baseline 1 |
|
Explanation on data presentation: Since more than one version may be installed in different areas, the information has to be done by parameter repetition using a single selection. |
|
|
General Explanations |
In case there is no GSM-R network available, please select “none”. In case you have installed FRS 7.3.0/SRS15.3.0, please select “Baseline 0 r3”. In case you have installed FRS 7.4.0/SRS 15.4.0, please select “Baseline 0 r4”. In case you have installed FRS 8.0.0/SRS 16.0.0, please select “Baseline 1”. In case you have installed a version prior to those (i.e. FRS 7/SRS 15 or FRS 6/SRS 14) please select “Previous version to Baseline 0”. |
|
Comments |
If "none" is chosen from the list of 1.1.1.3.3.1, all other GSM-R parameters (number 1.1.1.3.3.2 and 1.1.1.3.3.3) are not applicable. |
|
Reference |
CCS TSI: Table A2 of Annex 1 of Decision 2012/696/EU |
|
|
|
|
Number |
1.1.1.3.3.2 |
|
Title |
Number of active GSM-R mobiles (EDOR) or simultaneous communication session on- board for ETCS Level 2 (or level 3) needed to perform radio block centre handovers without having an operational disruption |
|
XML Name |
SOL Track Parameter CRG_NumActiveMob |
|
Definition |
|
|
applicability |
Y/N/NYA |
|
Applicable only when level 2 or 3 is selected for parameter 1.1.1.3.2.1 |
|
|
Can be repeated |
N |
|
Data presentation |
Single selection from the predefined list: 0 1 2 |
|
Explanation on data presentation: In case there is no ETCS Level 2 in the line (ETCS Level 1), please select “0”. In case there is ETCS Level 2 in the line, the minimum number of EDOR required on board would be 1. In case ETCS baseline 3 release 2 is selected, select “2” Please select ”1” or “2”, taking into account that TSI compliant trains may only be fitted with 1 EDOR. |
|
|
Reference |
No reference in TSI yet. |
|
Number |
1.1.1.3.3.3 |
|
Title |
Optional GSM-R functions |
|
XML Name |
SOL Track Parameter CRG_OptionalFunctions |
|
Definition |
Use of optional GSM-R functions which might improve operation on the line. They are for information only and not for network access criteria. |
|
Applicable |
Y/N/NYA |
|
Explanation on applicability: Not applicable (‘N’) when “none” is selected in parameter 1.1.1.3.3.1. |
|
|
Can be repeated |
Y |
|
Explanation on repeatability: To show more than one function by indicating single selection, the parameter has to be repeated as many times as many function has to be presented. |
|
|
Data presentation |
Single selection from the predefined list: Network selection manual (*1) Network selection via balise (*1) Network selection automatic (*1) Public emergency (112) available (*2) Broadcast calls (VBS) used (*3) Text message service used (SMS) (*4) Restriction of display of called/calling user (*5) Automatically forward of incoming call if no reply (*5) Automatically forward of incoming call if not reachable (*5) Use of chargeable Network Services (*6) General data applications (*7) ETCS RBC or other devices alerted when initiating a REC (Railway Emergency Call) (*8) Display at the controller terminal of the location of the mobile initiating a REC (Railway Emergency Call) (*8) Use of enhanced Railway Emergency Call (eREC) (*8) GSM-R shunting used (*8) Data recorded in case of Shunting Emergency Call (*8) Extended frequency bands used (*9) Other(*11): |
|
Explanation on data presentation: (*1) These inputs refer to the expected behaviour by your network, i.e. if you have any area or point where an automatic selection of network should be done or if you have any location where you have installed balises to instruct a change of radio network. In order to be able to attend to these indications (automatic network, network change by balise) some configuration is needed in the mobile. In case there is a balise used to announce the change of the network, or if there are locations where the network selection is planned by the IM to be done automatically (and not manually, as stated in the requirements). It should be considered as an item that is related to the design of the infrastructure. |
|
|
(*2) the possibility to dial 112 is something specific to the network that should be communicated to the vehicles accessing it. (*3) the use of broadcast calls is something specific to the network that has to be configured in it. (*4) it is something specific to the network that has to be configured in it if the service is provided. (*5) it is something specific to the network that has to be configured in it if the service is provided; something may need to be configured on the network but also in the mobile subscriber data if it wants to use the service. What is requested here is the information of the network capability. (*6) if they are configured on the network. Please indicate which in the “Other information” box. (*7) To be selected if other data applications, different from ETCS L2, can be used within the network – (*8) if it is configured on the network. “GSM-R Shunting used” in order to make public if the GSM-R is used in the network for shunting activities. (*9) Please specify in the “Other information“ box for which services /applications are they planned and which are the frequencies in use.
(*11): Please use this field to indicate any additional information on network
characteristics, e.g.; interference level, leading to the need of additional
on-board protection; |
|
|
|
|
|
|
|
Number |
1.1.1.3.3.3.1 |
|
Title |
Additional information on network characteristics |
|
XML Name |
SOL Track Parameter CRG_AdditionalnetworkInfo |
|
Definition |
Any additional information on network characteristics or corresponding document available from the IM and stored by the Agency, e.g.; interference level, leading to the recommendation of additional on-board protection |
|
Applicable |
Y/N/NYA |
|
Explanation on applicability: Not applicable (‘N’) when “none” is selected in parameter 1.1.1.3.3.1. |
|
|
Can be repeated |
Y |
|
Explanation on repeatability: |
|
|
Data presentation |
[Characterstring] |
|
|
|
|
explanations |
Please use this field to indicate any additional information on network. The document itself has to be upload by the NRE via the “reference document management” functionality. The reference of the document is provided for the parameter using the characterstring format. |
|
Reference |
|
|
|
|
|
Number |
1.1.1.3.3.3.2 |
|
Title |
GPRS for ETCS |
|
XML Name |
SOL Track Parameter CRG_GPRSForETCS |
|
Definition |
Indication if GPRS can be used for |
|
Applicable |
Y/N/NYA |
|
Explanation on applicability: Not applicable (‘N’) when “none” is selected in parameter 1.1.1.3.3.1 or when 1.1.1.3.2.1 is “N”, “NTC”, “0” or “1”. |
|
|
Can be repeated |
N |
|
Explanation on repeatability: |
|
|
Data presentation |
Single selection from the predefined list: Y / N |
|
|
|
|
explanations |
Indicate if GPRS can be used for ETCS |
|
Reference |
Sections of EIRENE and ETCS subsets for trackside in TSI |
|
|
|
|
|
|
|
Number |
1.1.1.3.3.3.3 |
|
Title |
Area of implementation of GPRS |
|
XML Name |
SOL Track Parameter CRG_GPRSAreaOfImpl |
|
Definition |
Indication of the area in which GPRS can be used for ETCS |
|
Applicable |
Y/N/NYA |
|
Explanation on applicability: Not applicable (‘N’) when “none” is selected in parameter 1.1.1.3.3.1 or when 1.1.1.3.2.1 is “N”, “NTC”, “0” or “1”. Applicable if the answer to 1.1.1.3.3.3.2 / GPRS for ETCS is Y |
|
|
Can be repeated |
Y |
|
Explanation on repeatability: |
|
|
Data presentation |
[Characterstring] |
|
|
|
|
explanations |
Since GPRS can be used for ETCS, indicate in which areas it is implemented (e.g: whole section, only between two signals, at the station…) |
|
Reference |
Sections of EIRENE optional for trackside in TSI |
|
|
|
|
Number |
1.1.1.3.3.4 |
|
Title |
Use of group 555 |
|
XML Name |
SOL Track Parameter CRG_Needof555 |
|
Definition |
Indication if group 555 is needed |
|
Applicable |
Y/N/NYA |
|
Explanation on applicability: Not applicable (‘N’) when “none” is selected in parameter 1.1.1.3.3.1. |
|
|
|
N |
|
Can be repeated |
Explanation on repeatability: |
|
Data presentation |
Selection from the predefined list: Y/N |
|
explanations |
|
|
Reference |
Sections of EIRENE not covered by references in TSI |
|
|
|
|
Number |
1.1.1.3.3.5 |
|
Title |
GSM-R networks covered by a roaming agreement |
|
XML Name |
SOL Track Parameter CRG_RoamingAgreement |
|
Definition |
Name of the own GSM-R network and list of GSM-R networks which are covered by a roaming agreement (for CS services.) |
|
Applicable |
Y/N/NYA |
|
Explanation on applicability: Not applicable (‘N’) when “none” is selected in parameter 1.1.1.3.3.1. |
|
|
Can be repeated |
Y |
|
Explanation on repeatability: |
|
|
Data presentation |
Single selection from the predefined list: GSM-R A (Austria) GSM-R AL (Albania) GSM-R B (Belgium) GSM-R BA (Bosnia Herzegovina) GSM-R BG (Bulgaria) GSM-R BY (Belarus) GSM-R CH (Switzerland) GSM-R CZ (Czech Rep.) GSM-R D (Germany) GSM-R DK (Denmark) GSM-R E (Spain) GSM-R EE (Estonia) GSM-R F (France) GSM-R FI (Finland) GSM-R GB (UK (Great Britain)) GSM-R GR (Greece) GSM-R HR (Croatia) GSM-R HU (Hungary) GSM-R I (Italy) GSM-R IE (Ireland) GSM-R IS (Iceland) GSM-R KO (Kosovo) GSM-R L (Luxembourg) GSM-R LT (Lithuania) GSM-R LV (Latvia) GSM-R MD (Moldova) GSM-R ME (Montenegro) GSM-R MK (Macedonia) GSM-R N (Norway) GSM-R NL (Netherlands) GSM-R P (Portugal) GSM-R PL (Poland) GSM-R RO (Romania) |
|
|
GSM-R RU (Russia) GSM-R S (Sweden) GSM-R SI (Slovenia) GSM-R SK (Slovakia) GSM-R SR (Serbia ) GSM-R TR (Turkey) GSM-R UA (Ukraine) |
|
|
|
|
explanations |
Name of the own GSM-R network and list of GSM-R networks which are covered by a roaming agreement for CS services. This list is managed by UIC. The Agency will monitor it in order to update the list of possible values when necessary. For Route Compatibility purposes and simplicity, the own network needs to be declared by the IM, so the RUs can systematically check the compatibility. For voice services, roaming for CS is applicable. For ETCS, as long as roaming for CS is ensured, the interoperability will be guaranteed. |
|
|
|
|
Reference |
Sections of EIRENE not covered by references in TSI |
|
|
|
|
Number |
1.1.1.3.3.6 |
|
Title |
Existence of roaming to public networks |
|
XML Name |
SOL Track Parameter CRG_RoamingPublic |
|
Definition |
Existence of roaming to a public networks (if roaming to a public network is configured, please indicate so) |
|
Applicable |
Y/N/NYA |
|
Explanation on applicability: Not applicable (‘N’) when “none” is selected in parameter 1.1.1.3.3.1. |
|
|
Can be repeated |
N |
|
Explanation on repeatability: |
|
|
Data presentation |
Selection from the predefined list: Y N |
|
explanations |
In case of y: provide the name of the public network in parameter 1.1.1.3.3.7 |
|
Reference |
Sections of EIRENE not covered by references in TSI |
|
|
|
|
Number |
1.1.1.3.3.7 |
|
Title |
Details on roaming to public networks |
|
XML Name |
SOL Track Parameter CRG_RoamingPublicDetails |
|
Definition |
If roaming to public networks is configured, please indicate to which networks, for which users and in which areas. |
|
Applicable |
Y/N/NYA |
|
Explanation on applicability: |
|
|
|
Applicable if the answer to parameter 1.1.1.3.3.6 / Existence of roaming to public networks is ‘Y’ |
|
Can be repeated |
N |
|
Explanation on repeatability: |
|
|
Data presentation |
Character string |
|
|
|
|
Explanations |
If roaming to a public network is configured, please indicate to which networks, for which users and in which areas. Please also add if there is any operational restriction for vehicles that cannot roam into any of the available public networks. If roaming to a public network is configured, please indicate to which networks, for which users and in which areas. Please list if any GSM-R functionality is not available when roaming to a public network (e.g. REC, Functional Addressing, Group Calls). Please also add if there is any operational restriction for vehicles that cannot roam into any of the available public networks. |
|
|
|
|
Reference |
|
|
|
|
|
|
|
|
Number |
1.1.1.3.3.8 |
|
Title |
No GSMR coverage |
|
XML Name |
SOL Track Parameter CRG_GSMRNoCoverage |
|
Definition |
Indication if there is a no GSMR coverage |
|
Applicable |
Y/N/NYA |
|
Explanation on applicability: Not applicable (‘N’) when “none” is selected in parameter 1.1.1.3.3.1. |
|
|
Can be repeated |
N |
|
Explanation on repeatability: |
|
|
Data presentation |
Single selection from the predefined list: Y / N |
|
|
|
|
explanations |
Indication if there is no GSMR coverage. This parameter is mainly to capture the case of Radio Hole functionality (lack of GSM-R coverage), that is foreseen in the ETCS specifications as packet 68. Another possible use is the declaration of a temporary situation where, although the area is in principle covered by GSM-R, there is a long-term outage or a project for replacement of the radio (i.e. a section that will not be covered with GSM-R for half a year or longer |
|
|
|
|
Reference |
Sections of EIRENE not covered by references in TSI |
|
|
|
|
|
|
|
Number |
1.1.1.3.3.9 |
|
Title |
Radio system compatibility voice |
|
XML Name |
SOL Track Parameter CRG_RadioCompVoice |
|
Definition |
Radio requirements used for demonstrating technical compatibility voice |
|
Applicable |
Y/N/NYA |
|
Explanation on applicability: Not applicable (‘N’) when “none” is selected in parameter 1.1.1.3.3.1. |
|
|
Can be repeated |
Y |
|
Explanation on repeatability: The vehicles are considered compatible with the infrastructure regarding this parameter, if matches any of the values declared. In case the value “Not Defined” or “RSC-EU-0” is used, is not expected to have repetitions with additional values. |
|
|
Data presentation |
Single selection from the predefined list: |
|
|
|
|
explanations |
As defined in the revised CCS TSI in sections 6.1.2.4 and 6.1.2.5, the Agency will “set up and manage in a technical document the set of checks to demonstrate the technical compatibility of an on-board subsystem with the trackside subsystem”. The predefined list of values will follow the changes in that technical document. Each set of checks will have a unique id, like “ESC-1” (final format not defined). The different values to be defined inside each network need to be submitted by each IM with the support of their suppliers to the Agency. (CCS TSI 6.1.2.4 and 6.1.2.5 – Regulation (EU) 2019/776). The Agency will then compile them in a Technical Document, give them an identifier, and after, these identifiers will be available for selection in RINF and ERA TV. Therefore, these values will not be available until the IM has communicated the checks to the Agency. There is information about the ESC/RSC and the submission to the Agency in the ERA webpage (Link). More information will be included in the CCS TSI application guide. The deadline set in the CCS TSI for IMs to complete this process is 16 January 2020. |
|
Reference |
Agency Technical Document ESC/RSC (https://www.era.europa.eu/sites/default/files/activities/docs/era_td-011rec1028_esc- rsc_technical_document_en.pdf). CCS TSI Regulation (EU) 2019/776 section 4.2.17 and 6.1.2.5 |
|
|
|
Not Defined
RSC-EU-0
RSC-ES-01-V
RSC-ES-02-V
RSC-ES-03-V
RSC-ES-04-V
RSC-ES-05-V
RSC-SE-01-V
RSC-FR-01-V
RSC-AT-01-V
RSC-BE-01-V
RSC-RO-01-V
RSC-DE-01-V
RSC-LU-01-V
RSC-CH-01-V
|
Number |
1.1.1.3.3.10 |
|
Title |
Radio system compatibility data |
|
XML Name |
SOL Track Parameter CRG_RadioCompData |
|
Definition |
Radio requirements used for demonstrating technical compatibility data voice |
|
Applicable |
Y/N/NYA |
|
Explanation on applicability: Not applicable (‘N’) when: |
|
|
Can be repeated |
Y |
|
Explanation of repeatability: The vehicles are considered compatible with the infrastructure regarding this parameter, if matches any of the values declared. In case the value “Not Defined” or “RSC-EU-0” is used, is not expected to have repetitions with additional values. |
|
|
Data presentation |
Single selection from the predefined list: |
|
explanations |
As defined in the revised CCS TSI in sections 6.1.2.4 and 6.1.2.5, the Agency will “set up and manage in a technical document the set of checks to demonstrate the technical compatibility of an on-board subsystem with the trackside subsystem”. The predefined |
“none” is selected in parameter 1.1.1.3.3.1 OR
parameter 1.1.1.3.3.1 is not “None” AND parameter 1.1.1.3.2.1 is not “2” or “3”.
Not Defined
RSC-EU-0
RSC-ES-01-D
RSC-ES-02-D
RSC-ES-03-D
RSC-ES-04-D
RSC-ES-05-D
RSC-SE-01-D
RSC-FR-01-D
RSC-AT-01-D
RSC-PL-01-D
RSC-ES-03.ALBALI-D
RSC-ES-03.ANTGRA-D
RSC-ES-03.CHATO-D
RSC-ES-03.BAFI-D
RSC-ES-03.CORMAL-D
RSC-ES-03.SAGTOL-D
RSC-ES-03.MADBCN-D
RSC-ES-03.MADVLL-D
RSC-ES-03.MONMUR-D
RSC-ES-03.MOTVLCALB-D
RSC-ES-03.OLMPED-D
RSC-ES-05.PLACACBAD-D
RSC-ES-03.TORMOT-D
RSC-ES-03.VALLEOBUR-D
RSC-ES-03.VILTAR-D
RSC-ES-05.HOSMAT-D
RSC-ES-04.LAXAVA-D
RSC-ES-04.ORESAN-D
RSC-ES-04.ARAVIL-D
RSC-ES-05.LEOPOL-D
RSC-ES-05.PEDORE-D
RSC-CH-01-D
|
|
list of values will follow the changes in that technical document. Each set of checks will have a unique id, like “ESC-1” (final format not defined). The different values to be defined inside each network need to be submitted by each IM with the support of their suppliers to the Agency. (CCS TSI 6.1.2.4 and 6.1.2.5 – Regulation (EU) 2019/776). The Agency will then compile them in a Technical Document, give them an identifier, and after, these identifiers will be available for selection in RINF and ERA TV. Therefore, these values will not be available until the IM has communicated the checks to the Agency. There is information about the ESC/RSC and the submission to the Agency in the ERA webpage (Link). More information will be included in the CCS TSI application guide. The deadline set in the CCS TSI for IMs to complete this process is 16 January 2020. |
|
Reference |
Agency Technical Document ESC/RSC (https://www.era.europa.eu/sites/default/files/activities/docs/era_td-011rec1028_esc- rsc_technical_document_en.pdf). CCS TSI Regulation (EU) 2019/776 section 4.2.17 and 6.1.2.5 |
|
|
|
|
Number |
1.1.1.3.4 |
|
Title |
Train detection systems fully compliant with the TSI |
|
XML Name |
CCD |
|
Can be repeated |
N |
|
Number |
1.1.1.3.4.1 |
|
Title |
Existence of train detection system fully compliant with the TSI |
|
XML Name |
SOL Track Parameter CCD_TSITrainDetection |
|
Definition |
Indication if there is any train detection system installed and fully compliant with the CCS TSI requirements. |
|
Applicable |
Y/NYA |
|
Can be repeated |
N |
|
Data presentation |
Single choice from the predefined list: Y N |
|
General Explanations |
Verification of compliance with TSI includes application of notified national rules (when they exist). |
|
Reference |
CCS TSI: Annex A Index 77 |
|
|
|
|
Number |
1.1.1.3.5 |
|
Title |
Train protection legacy systems |
|
XML Name |
CPO |
|
Can be repeated |
N |
|
|
|
|
|
1.1.1.3.5.3 |
|
|
Train protection legacy system |
|
|
SOL Track Parameter CPO_LegacyTrainProtection |
|
|
Indication of which class B system is installed |
|
Applicable |
Y/NYA |
|
Can be repeated |
Y |
|
Data presentation |
Single selection from the predefined list: None ALSN ASFA ATB First generation ATB new generation ATC v2 ATC vR ATP ATP-VR/RHK BACC CAWS Chiltern-ATP Crocodile DAAT EBICAB 700 BU EBICAB 700 PT EBICAB 900 ES EuroSIGNUM EuroZUB EVM GNT (Geschwindigkeitsüberwachung für NeiTech-Züge) GW ATP INDUSI I60 KCVB KCVP KVB KVBP LS LZB (LZB L72, LZB L72 CE I and LZB L72 CE II) LZB ES Mechanical Trainstops MEMOR II+ NEXTEO PKP radio system with Radiostop function PZB 90 RETB RSDD/SCMT SHP SSC TBL 1 TBL 2 TBL1+ TPWS/AWS TVM 300 TVM 430 ZUB 123 |
|
References |
version 4.0 of the TD/2011-11 List of CCS Class B systems |
|
Number |
1.1.1.3.6 |
|
Title |
Other radio systems |
|
XML Name |
CRS |
|
Can be repeated |
N |
|
|
|
|
Number |
1.1.1.3.6.1 |
|
Title |
Other radio systems installed (Radio Legacy Systems) |
|
XML Name |
SOL Track Parameter CRS_Installed |
|
Definition |
Indication if other radio systems in normal operation are installed line-side. Indication of radio legacy systems installed. |
|
Applicable |
Y/NYA |
|
Can be repeated |
Y |
|
Data presentation |
Single selection from the predefined list: None UIC Radio Chapter 1-4 UIC Radio Chapter 1-4+6 UIC Radio Chapter 1- 4 + 6 (Irish system) UIC Radio Chapter 1-4 (TTT radio system installed at Cascais line) TTT radio system CP_N PKP radio system TRS — The Czech Railways radio system LDZ radio system CH — Greek Railways radio system (VHF) UIC Radio Chapter Bulgaria The Estonian radio system The Lithuanian radio system 450 Mhz UIC (kanál C) Analogue Radio Germany - UIC 751 BOSCH GSM-P Multikom OMEGA RDZ - in compliance with UIC 751-3 RETB (voice) Radio Network of CFR SRO Shunting Radio Communication System ZUGFUNK 95 |
|
|
ZUGFUNK 2000 SRV Telecar 10/460 (AEG Mobile) |
|
Reference |
National Rules and version 4.0 of the TD/2011-11 List of CCS Class B systems, |
|
|
|
|
Number |
1.1.1.3.7 |
|
Title |
Train detection systems not fully compliant with the TSI |
|
XML Name |
CTD |
|
Can be repeated |
N |
|
|
|
|
Number |
1.1.1.3.7.1.1 |
|
Title |
Type of train detection system |
|
XML Name |
SOL Track Parameter CTD_DetectionSystem |
|
Definition |
Indication of types of train detection systems installed |
|
Applicable |
Y/N/NYA |
|
“N” for 1.1.1.3.7.1.1 will trigger “N” for parameters 1.1.1.3.7.1.2 to 1.1.1.3.7.23 NYA for 1.1.1.3.7.1.1 will trigger NYA for parameters 1.1.1.3.7.1.2 to 1.1.1.3.7.23 |
|
|
Can be repeated |
Y |
|
Explanation on repeatability: If this parameter is repeated, parameters 1.1.1.3.7.2 to 1.1.1.3.7.23 shall be created also for the corresponding type. These parameters are to be considered children of the current. But not all parameters are applicable to all types of train detection systems; it depends on the applicability condition. |
|
|
Data presentation |
Single selection from the predefined list: track circuit wheel detector loop |
|
Explanation on data presentation: Following parameters 1.1.1.3.7.2 -1.1.1.3.7.23 depend on which type of train detection is installed on the track. The option of ‘wheel detector’ has to be also selected for: wheel sensor for axle counter, pedal or treadle. |
|
|
Reference |
National Rules |
|
|
|
|
Number |
1.1.1.3.7.1.2 |
|
Title |
Type of track circuits or axle counter to which specific checks are needed |
|
XML Name |
SOL Track Parameter CTD_TCCheck |
|
Definition |
Indication of types of train detection systems to which specific checks are needed |
|
Applicable |
Y/N/NYA |
|
|
|
|
Can be repeated |
Y |
|
Explanation on repeatability: An XML attribute called “Set” will be used to link the value of this parameter to the train detection type. |
|
|
Data presentation |
Single selection from the predefined list: Direct current Track circuit 50Hz Track circuit Zp30K / Zp30H 83.3 Hz track circuit 125 Hz track circuit ZP 43 E (manufactured prior to 2005) 83.3 Hz and 125 Hz track circuits 83.3 Hz track circuit and ZP 43 E (manufactured prior to 2005) 125 Hz track circuit and ZP 43 E (manufactured prior to 2005) 83.3 Hz and 125 Hz track circuits and ZP 43 E (manufactured prior to 2005) EBÜT 80 axle counter WSSB track circuit Siemens 100Hz (106,7Hz) track circuit Thales 100Hz (106,7Hz) track circuit |
|
Explanation on data presentation: |
|
|
Reference |
National Rules |
|
|
|
|
Number |
1.1.1.3.7.1.3 |
|
Title |
Document with the procedure(s) related to the type of track circuits declared in 1.1.1.3.7.1.2 |
|
XML Name |
SOL Track Parameter CTD_TCCheckDocRef |
|
Definition |
Electronic document available in two EU languages from the IM stored by the Agency with precise procedures for the specific check to be performed for train detection systems identified in 1.1.1.3.7.1.2. |
|
Applicable |
Y/N/NYA |
|
the applicability remains the latitude of the IM |
|
|
Can be repeated |
Y |
|
Explanation on repeatability: An XML attribute called “Set” will be used to link the value of this parameter to the train detection type. |
|
|
Data presentation |
Single selection from the predefined list: CharacterString |
|
Explanations |
The document itself has to be upload by the NRE via the “reference document management” functionality. The reference of the document is provided for the parameter using the characterstring format. |
|
Reference |
National Rules |
|
Number |
1.1.1.3.7.1.4 |
|
Title |
Section with train detection limitation |
|
XML Name |
SOL Track Parameter CTD_TCLimitation |
|
Definition |
Specific for route compatibility check on French network. Sections with: -1 Tonnage circulated per track is inferior to 15000 tons/day/track -2 Directional Interlocking -3 45-second delay for directional interlocking -4 Installation with track circuit announcement -5 Absence of a shunting assistance pedal in the normal direction of circulation for non-reversible double track lines -6 Absence of a shunting assistance pedal regardless of the direction of traffic for single track lines and tracks for two way working -7 Absence of a pedal announcement mechanism -8 45-second delay for specific announcement reset devices |
|
Applicable |
Y/N/NYA |
|
|
|
|
Can be repeated |
Y |
|
Explanation on repeatability: An XML attribute called “Set” will be used to link the value of this parameter to the train detection type. |
|
|
Data presentation |
Single selection from the predefined list: Single selection from the predefined list: [Y / N ]+N The number N is between 1 and 8 as from the definition above |
|
Explanation on data presentation: |
|
|
Reference |
National Rules |
|
|
|
|
Number |
1.1.1.3.7.2.1 |
|
Title |
TSI compliance of maximum permitted distance between two consecutive axles |
|
XML Name |
SOL Track Parameter CTD_TSIMaxDistConsecutiveAxles |
|
Definition |
Indication whether required distance is compliant with the TSI. |
|
Explanation on Definition |
Related to the minimum length of train detection section. This requirement is related to the minimum length of a signalling section, so that if a vehicle does not bridge it, making the train detection system reports it as “unoccupied”. |
|
Applicable |
Y/N/NYA |
|
Can be repeated |
Y but only one per train detection type (CTD_DetectionSystem) An XML attribute called “Set” will be used to link the value of this parameter to the train detection type. |
|
Data presentation |
Single selection from the predefined list: TSI compliant Not TSI compliant |
|
Reference |
CCS TSI: 3.1.2.1 of Annex A, Index 77 |
|
|
|
|
Number |
1.1.1.3.7.2.2 |
|
Title |
Maximum permitted distance between two consecutive axles in case of TSI non- compliance |
|
XML Name |
SOL Track Parameter CTD_MaxDistConsecutiveAxles |
|
Definition |
Indication of maximum permitted distance between two consecutive axles in case of TSI non-compliance, given in millimetres |
|
Applicable |
Y/N/NYA |
|
|
Applicable (‘Y’) when in 1.1.1.3.7.2.1 selected option is ‘Not TSI compliant’ |
|
Can be repeated |
Y but only one per train detection type (CTD_DetectionSystem) An XML attribute called “Set” will be used to link the value of this parameter to the train detection type. Example: <SOLTrackParameter ID="CTD_DetectionSystem" IsApplicable="Y" Value="10" Set="track circuit"/> <SOLTrackParameter ID="CTD_TSIMaxDistConsecutiveAxles" IsApplicable="Y" Value="20" Set="track circuit"/> <SOLTrackParameter ID="CTD_MaxDistConsecutiveAxles" IsApplicable="Y" Value="123" Set="track circuit"/> |
|
Data presentation |
[NNNNN] |
|
Reference |
CCS TSI: 3.1.2.1 of Annex A, Index 77 |
|
|
|
|
Number |
1.1.1.3.7.3 |
|
Title |
Minimum permitted distance between two consecutive axles |
|
XML Name |
SOL Track Parameter CTD_MinDistConsecutiveAxles |
|
Definition |
Indication of distance given in millimetres. |
|
Applicable |
Y/N/NYA |
|
Explanation on applicability: Applicable (‘Y’) when in parameter 1.1.1.3.7.1.1 the selected option is ‘wheel detector’ |
|
|
Can be repeated |
Y An XML attribute called “Set” will be used to link the value of this parameter to the train detection type (see example given for 1.1.1.3.7.2.2 / CTD_TSIMaxDistConsecutiveAxles). |
|
Data presentation |
[NNNN] |
|
General Explanation |
The distance is that corresponding to the maximum speed of the SoL. The CCS TSI gives formula in accordance with the gauge that apply if the maximum line speed is lower or equal to 350 km/h. It is an open point for line speed higher than 350 km/h. Axle counter systems have to be able to distinguish the detection of an axle by 2 subsequent counters with sufficient resolution; otherwise, the result will be a count- error. |
|
Reference |
CCS TSI: Annex A, index 77 section 3.1.2.2 and 3.1.2.3 (open point) CCS TSI: Index 77 updated (V2.0 of ERA/ERTMS/033281) |
|
|
|
|
Number |
1.1.1.3.7.4 |
|
Title |
Minimum permitted distance between first and last axle |
|
XML Name |
SOL Track Parameter CTD_MinDistFirstLastAxles |
|
Definition |
Indication of distance given in millimetres. |
|
Explanation on Definition |
Related to track circuits or respective specific cases. The electrical joints between adjacent track circuits may have an area where the detection of an axle of a vehicle is not ensured. |
|
Applicable |
Y/N/NYA |
|
Explanation on applicability: Applicable (‘Y’) only when for parameter 1.1.1.3.7.1.1 the selected option is ‘track circuits’. |
|
|
Can be repeated |
Y An XML attribute called “Set” will be used to link the value of this parameter to the train detection type (see example given for 1.1.1.3.7.2.2 / CTD_TSIMaxDistConsecutiveAxles). |
|
Data presentation |
[NNNNN] |
|
Reference |
CCS TSI: 3.1.2.4 of Annex A, Index 77 |
|
|
|
|
Number |
1.1.1.3.7.5 |
|
Title |
Maximum distance between end of train and first axle |
|
XML Name |
SOL Track Parameter CTD_MaxDistEndTrainFirstAxle |
|
Definition |
Indication of maximum distance between end of the train and first axle, given in millimetres, applicable for both sides (front and rear) of a vehicle or train. |
|
Applicable |
Y/N/NYA |
|
Explanation on applicability: Applicable (‘Y’) only when for parameter 1.1.1.3.7.1.1 the selected option is ‘track circuits’ or ‘wheel detector’. A train detection system shall be able to detect: |
|
|
Can be repeated |
Y but only one per train detection type (CTD_DetectionSystem) An XML attribute called “Set” will be used to link the value of this parameter to the train detection type (see example given for 1.1.1.3.7.2.2 / CTD_TSIMaxDistConsecutiveAxles). |
|
Data presentation |
[NNNN] |
|
General Explanations |
Length given in millimetres. Related to track circuits and axle counters. A train detection system shall be able to detect the first axle before the nose of the train reaches a danger point ahead as well as the last axle until the tail of the train has left the danger point. 'Nose' is applicable for both sides (front and rear) of a vehicle or train. |
|
Reference |
CCS TSI: 3.1.2.5 (HS) and 3.1.2.6 (other lines) of Annex A, Index 77 |
|
|
|
|
Number |
1.1.1.3.7.6 |
|
Title |
Minimum permitted width of the rim |
|
XML Name |
SOL Track Parameter CTD_MinRimWidth |
|
Definition |
Indication of width given in millimetres. |
|
Explanation on Definition |
Related to axle counters, pedals and treadles. The detection field of the axle counter is influenced by the wheel which passes. The rim width has to be big enough to influence the field sufficiently to ensure appropriate detection. |
|
Applicable |
Y/N/NYA |
|
Applicable (‘Y’) only when for parameter 1.1.1.3.7.1.1 the selected option is ‘wheel detector’. |
|
|
Can be repeated |
Y An XML attribute called “Set” will be used to link the value of this parameter to the train detection type (see example given for 1.1.1.3.7.2.2 / CTD_TSIMaxDistConsecutiveAxles). |
|
Data presentation |
Predefined CharacterString: [NNN] |
|
Reference |
LOC&PAS TSI: 4.2.3.5.2.2, Table 5. |
|
|
|
the first axle before the nose of the train reaches a danger point ahead
the last axle until the tail of the train has passed the danger point.
|
Number |
1.1.1.3.7.7 |
|
Title |
Minimum permitted wheel diameter |
|
XML Name |
SOL Track Parameter CTD_MinWheelDiameter |
|
Definition |
Indication of wheel diameter given in millimetres. |
|
Explanation on Definition |
Compatibility with axle counters. The area of the influence (on the flange surface of a wheel) of the detection field of the axle counter is related to the wheel diameter. |
|
Applicable |
Y/N/NYA |
|
Explanation on applicability: Applicable (‘Y’) only when for parameter 1.1.1.3.7.1.1 the selected option is ‘wheel detector’. |
|
|
Can be repeated |
Y An XML attribute called “Set” will be used to link the value of this parameter to the train detection type (see example given for 1.1.1.3.7.2.2 / CTD_TSIMaxDistConsecutiveAxles). |
|
Data presentation |
[NNN] |
|
References |
LOC&PAS TSI: 4.2.3.5.2.2, Table 5 |
|
|
|
|
Number |
1.1.1.3.7.8 |
|
Title |
Minimum permitted thickness of the flange |
|
XML Name |
SOL Track Parameter CTD_MinFlangeThickness |
|
Definition |
Indication of flange thickness given in millimetres. |
|
Applicable |
Y/N/NYA |
|
Explanation on applicability: Applicable (‘Y’) only when for parameter 1.1.1.3.7.1.1 the selected option is ‘wheel detector’. |
|
|
Can be repeated |
Y An XML attribute called “Set” will be used to link the value of this parameter to the train detection type (see example given for 1.1.1.3.7.2.2 / CTD_TSIMaxDistConsecutiveAxles). |
|
Data presentation |
[NN.N] |
|
General Explanations |
Compatibility with axle counters, pedals and treadles. The detection field of the axle counter is influenced by the wheel which passes. The flange thickness has to be big enough to influence the field sufficiently to ensure appropriate detection. Thickness given in millimetres with decimals. The TSI makes distinction between several values depending on the wheel diameter; The less value acceptable by the infrastructure (axle counters, pedals and treadles) has to be provided. |
|
Reference |
LOC&PAS TSI: 4.2.3.5.2.2, Table 5 |
|
Number |
1.1.1.3.7.9 |
|
Title |
Minimum permitted height of the flange |
|
XML Name |
SOL Track Parameter CTD_MinFlangeHeight |
|
Definition |
Indication of height of flange given in millimetres. |
|
Applicable |
Y/N/NYA |
|
Explanation on applicability: Applicable (‘Y’) only when for parameter 1.1.1.3.7.1.1 the selected option is ‘wheel detector’. |
|
|
Can be repeated |
Y An XML attribute called “Set” will be used to link the value of this parameter to the train detection type (see example given for 1.1.1.3.7.2.2 / CTD_TSIMaxDistConsecutiveAxles). |
|
Data presentation |
[NN.N] |
|
Explanation on data presentation: Height given in millimetres with decimals. |
|
|
General Explanations |
Compatibility with axle counters, pedals and treadles. The detection field of the axle counter is influenced by the wheel which passes. The flange height has to be big enough to influence the field sufficiently to ensure appropriate detection. The TSI makes distinction between several values depending on the wheel diameter; The least acceptable value by the infrastructure has to be provided. |
|
Reference |
LOC&PAS TSI: 4.2.3.5.2.2, Table 5 |
|
|
|
|
Number |
1.1.1.3.7.10 |
|
Title |
Maximum permitted height of the flange |
|
XML Name |
SOL Track Parameter CTD_MaxFlangeHeight |
|
Definition |
Indication of height of flange given in millimetres. |
|
Applicable |
Y/N/NYA |
|
Explanation on applicability: Applicable (‘Y’) only when for parameter 1.1.1.3.7.1.1 the selected option is ‘wheel detector’. |
|
|
Can be repeated |
Y An XML attribute called “Set” will be used to link the value of this parameter to the train detection type (see example given for 1.1.1.3.7.2.2 / CTD_TSIMaxDistConsecutiveAxles). |
|
Data presentation |
[NN.N] |
|
General Explanations |
Compatibility with axle counters, pedals and treadles. The detection field of the axle counter is influenced by the wheel which passes. For the flange height the range of the dimension Sh(min) – Sh(max) has to be defined. Height given in millimetres with decimals. The TSI makes distinction between several values depending on the wheel diameter; The least acceptable value by the infrastructure has to be provided. |
|
Reference |
LOC&PAS TSI: 4.2.3.5.2.2, Table 5 |
|
|
|
|
Number |
1.1.1.3.7.11.1 |
|
Title |
Minimum permitted axle load per category of Vehicle |
|
XML Name |
SOL Track Parameter CTD_MinAxleLoadByVehicleCat |
|
Definition |
Indication of load given in tons depending of the category of vehicle. |
|
Applicable |
Y/N/NYA |
|
Explanation on applicability: Applicable (‘Y’) only when for parameter 1.1.1.3.7.1.1 the selected option is ‘track circuit’ or ‘wheel detector’. |
|
|
Can be repeated |
Y An XML attribute called “Set” will be used to link the value of this parameter to the train detection type (see example given for 1.1.1.3.7.2.2 / CTD_TSIMaxDistConsecutiveAxles). |
|
Data presentation |
Single selection from the predefined list representing categories of vehicle which is amended by value of minimum permitted axle load [tons] for a specific category: Vehicle axle load Harmonized parameter for 1435mm, 1524mm, 1600mm and 1668mm track gauge: The axle load is [NN.N] at least 3,5 t for vehicles with more than 4 axles and wheel tread brakes [NN.N] at least 4 t for vehicles with 4 axles and wheel tread brakes [NN.N] at least 5 t for other vehicles (that is, vehicles that do not fall into categories 1 or 2) |
|
General Explanations |
Compatibility with track circuits, pedals and treadles. A minimum axle load will activate pedals and treadles. Also, minimum axle load will have a beneficiary effect on the resistance between wheel and track, which is important for the operation of track circuits. Load given in tons (unit of mass). In case that there is no restriction for “wheel detector’ the Value =0.0 can be given” |
|
Reference |
CCS TSI: Annex A Index 77 3.1.7.1 |
|
|
|
|
|
|
|
Number |
1.1.1.3.7.12 |
|
Title |
TSI compliance of rules for metal-free space around wheels |
|
XML Name |
SOL Track Parameter CTD_TSIMetalFree |
|
Definition |
Indication whether rules are compliant with the TSI. |
|
Applicable |
Y/N/NYA |
|
Explanation on applicability: Applicable (‘Y’) only when for parameter 1.1.1.3.7.1.1 the selected option is ‘wheel detector’. |
|
|
Can be repeated |
Y An XML attribute called “Set” will be used to link the value of this parameter to the train detection type (see example given for 1.1.1.3.7.2.12/ CTD_TSIMaxDistConsecutiveAxles). |
|
Data presentation |
Single selection from the predefined list: |
|
|
TSI compliant not TSI compliant |
|
General Explanations |
Compatibility with wheel sensors for axle counters. The principle of axle counters is based on the distortion of an electromagnetic field. The distortion should occur only by the passage of the wheel and not of the surrounding parts of rolling stock. |
|
Comments |
Verification of compliance with TSI includes application of notified national rules (when they exist) in case of part covered by open point. |
|
Reference |
CCS TSI: 3.1.3.5, Annex A, Index 77 |
|
|
|
|
Number |
1.1.1.3.7.13 |
|
Title |
TSI compliance of rules for vehicle metal construction |
|
XML Name |
SOL Track Parameter CTD_TSIMetalConstruction |
|
Definition |
Indication whether rules are compliant with the TSI. |
|
Applicable |
Y/N/NYA |
|
Explanation on applicability: Applicable (‘Y’) only when for parameter 1.1.1.3.7.1.1 the selected option is ‘loop’. |
|
|
Can be repeated |
Y An XML attribute called “Set” will be used to link the value of this parameter to the train detection type (see example given for 1.1.1.3.7.2.2 / CTD_TSIMaxDistConsecutiveAxles). |
|
Data presentation |
Single selection from the predefined list: TSI compliant not TSI compliant |
|
General Explanations |
Compatibility with induction loops. The metal-mass influences loop detection systems. Verification of compliance with TSI includes application of notified national rules (when they exist) concerning the part covered by open point. |
|
Reference |
CCS TSI: 3.1.7.2 of Annex A, Index 77 |
|
|
|
|
Number |
1.1.1.3.7.14 |
|
Title |
TSI compliance of Ferromagnetic characteristics of wheel material required |
|
XML Name |
SOL Track Parameter CTD_TSIFerroWheelMat |
|
Definition |
Indication whether rules are compliant with the TSI. |
|
Applicable |
Y/N/NYA |
|
Explanation on applicability: Applicable (‘Y’) only when for parameter 1.1.1.3.7.1.1 the selected option is ‘wheel detector’. |
|
|
Can be repeated |
Y An XML attribute called “Set” will be used to link the value of this parameter to the train detection type (see example given for 1.1.1.3.7.2.2 / CTD_TSIMaxDistConsecutiveAxles). |
|
Data presentation |
Single selection from the predefined list: TSI compliant not TSI compliant |
|
General Explanations |
Compatibility with wheel sensors for axle counters. This characteristic is necessary to generate the distortion of the electromagnetic field of axle counters, to ensure appropriate detection. |
|
Reference |
CCS TSI: 3.1.3.6, Annex A, Index 77 |
|
|
|
|
Number |
1.1.1.3.7.15.1 |
|
Title |
TSI compliance of maximum permitted impedance between opposite wheels of a wheelset |
|
XML Name |
SOL Track Parameter CTD_TSIMaxImpedanceWheelset |
|
Definition |
Indication whether rules are compliant with the TSI. |
|
Applicable |
Y/N/NYA |
|
Explanation on applicability: Applicable (‘Y’) only when for parameter 1.1.1.3.7.1.1 the selected option is ‘track circuit’. |
|
|
Can be repeated |
Y An XML attribute called “Set” will be used to link the value of this parameter to the train detection type (see example given for 1.1.1.3.7.2.2 / CTD_TSIMaxDistConsecutiveAxles). |
|
Data presentation |
Single selection from the predefined list: TSI compliant Not TSI compliant |
|
General Explanations |
Compatibility with track circuits. A track circuit is only able to detect rolling stock if the impedance between rails does not exceed a certain value. |
|
Reference |
CCS TSI 3.1.9 Annex A, Index 77 |
|
|
|
|
Number |
1.1.1.3.7.15.2 |
|
Title |
Maximum permitted impedance between opposite wheels of a wheelset when not TSI compliant |
|
XML Name |
SOL Track Parameter CTD_MaxImpedanceWheelset |
|
Definition |
The value of maximum permitted impedance given in ohm in case of TSI non- compliance. |
|
Applicable |
Y/N/NYA |
|
Explanation on applicability: Applicable (‘Y’) only when for parameter 1.1.1.3.7.15.1 the selected option is ‘Not TSI compliant’ |
|
|
Can be repeated |
Y An XML attribute called “Set” will be used to link the value of this parameter to the train detection type (see example given for 1.1.1.3.7.2.2 / CTD_TSIMaxDistConsecutiveAxles). |
|
Data presentation |
[N.NNN] |
|
General Explanations |
A track circuit is only able to detect rolling stock if the impedance between rails does not exceed a certain value, given by the impedance of the opposite wheels of the wheelsets and the contact resistance at the wheel-rail surface. The interface requirement given here is only related to the electrical resistance between the running surfaces of the opposite wheels of a wheelset. Remark: operational rules may apply to ensure that a sufficiently low value of the contact resistance is maintained during service: see 3.1.4 (Use of sanding equipment), 3.1.5 (On board flange lubrication) and 3.1.6 (Use of composite brake blocks). |
|
Reference |
CCS TSI 3.1.9 Annex A, Index 77 |
|
|
|
|
Number |
1.1.1.3.7.17 |
|
Title |
Maximum sanding output Maximum amount of sand |
|
XML Name |
SOL Track Parameter CTD_MaxSandOutput |
|
Definition |
Maximum amount of sand within accepted on the track. |
|
Applicable |
Y/N/NYA |
|
Applicable (‘Y’) only when for parameter 1.1.1.3.7.1.1 the selected option is ‘track
circuit’ |
|
|
Can be repeated |
Y An XML attribute called “Set” will be used to link the value of this parameter to the train detection type (see example given for 1.1.1.3.7.2.2 / CTD_TSIMaxDistConsecutiveAxles). |
|
Data presentation |
[NNNNN] Single selection from the predefined list: TSI compliant when speed lower than140km/h Not TSI compliant when speed lower than140km/h TSI compliant when speed higher than140km/h Not TSI compliant when speed higher than140km/h |
|
Reference |
CCS TSI: 3.1.4.1 of Annex A, Index 77 |
|
|
|
|
Number |
1.1.1.3.7.18 |
|
Title |
Sanding override by driver required |
|
XML Name |
SOL Track Parameter CTD_SandDriverOverride |
|
Definition |
Indication whether possibility to activate/deactivate sanding devices by driver, according to instructions from the Infrastructure Manager, is required or not. |
|
Explanation on Definition |
Compatibility with track circuits at places where the use of sanding is not permitted. |
|
Applicable |
Y/N/NYA |
|
Applicable (‘Y’) only when for parameter 1.1.1.3.7.1.1 the selected option is ‘track circuit’. |
|
|
Can be repeated |
Y An XML attribute called “Set” will be used to link the value of this parameter to the train detection type (see example given for 1.1.1.3.7.2.2 / CTD_TSIMaxDistConsecutiveAxles). |
|
Data presentation |
Single selection from the predefined list: Y N |
|
Reference |
OPE TSI: Appendix B (C1) |
|
|
|
|
|
1.1.1.3.7.19 |
|
|
TSI Compliance of rules on sand characteristics |
|
|
SOL Track Parameter CTD_TSISandCharacteristics |
|
|
Indication whether rules are compliant with the TSI. |
|
Explanation on Definition |
Compatibility with track circuits where sanding is permitted. |
|
|
Y/N/NYA |
|
Applicable |
Explanation on applicability: Applicable (‘Y’) only when for parameter 1.1.1.3.7.1.1 the selected option is ‘track circuit’ and when the track belongs to a 1520 mm gauge. |
|
Can be repeated |
Y An XML attribute called “Set” will be used to link the value of this parameter to the train detection type (see example given for 1.1.1.3.7.2.2 / CTD_TSIMaxDistConsecutiveAxles). |
|
Data presentation |
Single selection from the predefined list: TSI compliant Not TSI compliant |
|
Reference |
CCS TSI: 3.1.4.2 of Annex A, Index 77; open point for 1435 mm gauge |
|
|
|
|
Number |
1.1.1.3.7.20 |
|
Title |
Existence of rules on on-board flange lubrication |
|
XML Name |
SOL Track Parameter CTD_FlangeLubeRules |
|
Definition |
Indication whether rules for activation or deactivation of flange lubrication exist. |
|
Explanation on Definition |
Concerns activation or deactivation of flange lubrication according to instructions from IM, for compatibility with the track circuits. |
|
Applicable |
Y/N/NYA |
|
Explanation on applicability: Applicable (‘Y’) only when for parameter 1.1.1.3.7.1.1 the selected option is ‘track circuit’. |
|
|
Can be repeated |
Y An XML attribute called “Set” will be used to link the value of this parameter to the train detection type (see example given for 1.1.1.3.7.2.2 / CTD_TSIMaxDistConsecutiveAxles). |
|
Data presentation |
Single selection from the predefined list: Y N |
|
References |
LOC&PAS TSI: 7.5.3.1 CCS TSI: 3.1.5 of Annex A, Index 77 |
|
|
|
|
Number |
1.1.1.3.7.21 |
|
Title |
TSI compliance of rules on the use of composite brake blocks |
|
XML Name |
SOL Track Parameter CTD_TSICompositeBrakeBlocks |
|
Definition |
Indication whether rules are compliant with the TSI. |
|
Applicable |
Y/N/NYA |
|
Explanation on applicability: Applicable (‘Y’) only when for parameter 1.1.1.3.7.1.1 the selected option is ‘track circuit’. |
|
|
Can be repeated |
Y |
|
|
An XML attribute called “Set” will be used to link the value of this parameter to the train detection type (see example given for 1.1.1.3.7.2.2 / CTD_TSIMaxDistConsecutiveAxles). |
|
Data presentation |
Single selection from the predefined list: TSI compliant Not TSI compliant |
|
General Explanation |
Composite brake blocks can create an isolating film between wheels and rail compromising detection by track circuits. |
|
References |
LOC&PAS TSI Appendix J-2, index 1, clause 3.1.6 CCS TSI: 3.1.6 of Annex A, Index 77 |
|
|
|
|
Number |
1.1.1.3.7.22 |
|
Title |
TSI compliance of rules on shunt assisting devices |
|
XML Name |
SOL Track Parameter CTD_TSIShuntDevices |
|
Definition |
Indication whether rules are compliant with the TSI. |
|
Applicable |
Y/N/NYA |
|
Explanation on applicability: Applicable (‘Y’) only when for parameter 1.1.1.3.7.1.1 the selected option is ‘track circuit’. |
|
|
Can be repeated |
Y An XML attribute called “Set” will be used to link the value of this parameter to the train detection type (see example given for 1.1.1.3.7.2.2 / CTD_TSIMaxDistConsecutiveAxles). |
|
Data presentation |
Single selection from the predefined list: TSI compliant Not TSI compliant |
|
General Explanations |
In some cases, shunt assisting devices may be necessary to operate track circuits. According to the TSI, they should not be required. |
|
Reference |
CCS TSI: 3.1.8 of Annex A, Index 77 |
|
|
|
|
Number |
1.1.1.3.7.23 |
|
Title |
TSI compliance of rules on combination of RST characteristics influencing shunting impedance |
|
XML Name |
SOL Track Parameter CTD_TSIRSTShuntImpedance |
|
Definition |
Indication whether rules are compliant with the TSI. |
|
Applicable |
Y/N/NYA |
|
Explanation on applicability: Applicable (‘Y’) only when for parameter 1.1.1.3.7.1.1 the selected option is ‘track circuit’. |
|
|
Can be repeated |
Y An XML attribute called “Set” will be used to link the value of this parameter to the train detection type (see example given for 1.1.1.3.7.2.2 / CTD_TSIMaxDistConsecutiveAxles). |
|
Data presentation |
Single selection from the predefined list: TSI compliant Not TSI compliant |
|
General Explanations |
The composition of a train may impact on the compatibility with track circuits’ detection. |
|
Reference |
CCS TSI: 3.1.10 of Annex A, Index 77 |
|
|
|
|
Number |
1.1.1.3.8 |
|
Title |
Transitions between systems |
|
XML Name |
CTS |
|
Can be repeated |
N |
|
|
|
|
Number |
1.1.1.3.8.1 |
|
Title |
Existence of switch over between different protection, control and warning systems while running |
|
XML Name |
SOL Track Parameter CTS_SwitchProtectControlWarn |
|
Definition |
Indication whether a switch over between different systems whilst running exist |
|
Applicable |
Y/N/NYA |
|
Explanation on applicability: Applicable (‘Y’) when at least two different protection, control and warning systems exist. |
|
|
Can be repeated |
N |
|
Data presentation |
Single selection from the predefined list: Y N |
|
General Explanations |
Switch over between different systems whilst running. Installation depends on local conditions. |
|
Reference |
CCS TSI and national rules |
|
|
|
|
Number |
1.1.1.3.8.2 |
|
Title |
Existence of switch over between different radio systems |
|
XML Name |
SOL Track Parameter CTS_SwitchRadioSystem |
|
Definition |
Indication whether a switch over between different radio systems and no communication system whilst running exist |
|
Applicable |
Y/N/NYA |
|
Explanation on applicability: Applicable (‘Y’) when at least two different radio systems exist. |
|
|
Can be repeated |
N |
|
Data presentation |
Single selection from the predefined list: Y N |
|
General Explanations |
Switch over between different radio systems and no communication system whilst running. Installation depends on local conditions. The “Indication if other radio systems in normal operation are installed line-side” is given in parameter 1.1.1.3.6.1 / SOL Track Parameter CRS_Installed”. |
|
Reference |
CCS TSI and national rules |
|
|
|
|
Number |
1.1.1.3.9 |
|
Title |
Parameters related to electromagnetic interferences |
|
XML Name |
CEI |
|
Can be repeated |
N |
|
|
|
|
Number |
1.1.1.3.9.1 |
|
Title |
Existence and TSI compliance of rules for magnetic fields emitted by a vehicle |
|
XML Name |
SOL Track Parameter CEI_TSIMagneticFields |
|
Definition |
Indication whether rules exist and are compliant with the TSI. |
|
Applicable |
Y/N/NYA |
|
Explanation on applicability: Applicable (‘Y’) only when for parameter 1.1.1.3.7.1 the selected option is ‘wheel detector’. |
|
|
Can be repeated |
N |
|
Data presentation |
Single selection from the predefined list: none TSI compliant Not TSI compliant |
|
General Explanations |
Compatibility with wheel detectors. The electromagnetic fields generated by rolling stock can interfere with the operation of axle counters and wheel detectors. ‘none’ means that the rules do not exist. ‘TSI compliant’ means the rules exist and are compliant with the frequency management specified in the TSI ‘Not TSI compliant’ means the rules exist and are not compliant with the frequency management specified in the TSI |
|
Comments |
Verification of compliance with TSI includes application of notified national rules (when they exist) in case of part covered by open point. |
|
Reference |
CCS TSI: 3.2 of Annex A, Index 77 |
|
|
|
|
Number |
1.1.1.3.9.2 |
|
Title |
Existence and TSI compliance of limits in harmonics in the traction current of vehicles |
|
XML Name |
SOL Track Parameter CEI_TSITractionHarmonics |
|
Definition |
Indication whether rules exist and are compliant with the TSI. |
|
Applicable |
Y/N/NYA |
|
Explanation on applicability: Applicable (‘Y’) only when for parameter 1.1.1.3.7.1 the selected option is ‘wheel detector’ or ‘track circuit’. |
|
|
Can be repeated |
N |
|
Data presentation |
Single selection from the predefined list: none TSI compliant Not TSI compliant |
|
General Explanations |
Compatibility with track circuits and wheel detectors of axle counters. The harmonics in the traction current in the rails can interfere with the operation of track circuits. The DC current in the rails may saturate the detectors of the axle counters, preventing their operation. ‘none’ shall be selected when respective national rules do not exist. |
|
Comments |
Verification of compliance with TSI includes application of notified national rules (when they exist) in case of part covered by open point. |
|
Reference |
LOC&PAS TSI : Appendix J-2, index 1, clause 3.2.2 |
|
|
|
|
Number |
1.1.1.3.10 |
|
Title |
Line-side system for degraded situation |
|
XML Name |
CLD |
|
Can be repeated |
N |
|
|
|
|
Number |
1.1.1.3.10.1 |
|
Title |
ETCS level for degraded situation |
|
XML Name |
SOL Track Parameter CLD_ETCSSituation |
|
Definition |
ERTMS / ETCS application level for degraded situation related to the track side equipment |
|
Applicable |
Y/N/NYA |
|
Explanation on applicability: ‘N’=not applicable shall be selected when ETCS is not installed (selection of parameter 1.1.1.3.2.1 is ‘no’). |
|
|
Can be repeated |
Y |
|
Data presentation |
Single selection from the predefined list: none 0 1 2 3 NTC |
|
General Explanations |
System for degraded situation. In case of failure of the ETCS Level for normal operation, train movement can be supervised in another ETCS Level. Example: Level 1 as a degraded mode for Level 2. If the actual level (see 1.1.1.3.2.1) was "no", none degradation is possible, so only ‘none’ level is possible for degraded case. |
|
Comments |
It assumed that the degraded level has to be lower than the actual operating level. |
|
References |
OPE TSI: 4.2.1.2.1 and 4.4 National rules |
|
Number |
1.1.1.3.10.2 |
|
Title |
Other train protection, control and warning systems for degraded situation |
|
XML Name |
SOL Track Parameter CLD_OtherProtectControlWarn |
|
Definition |
Indication of existence of other systems than ETCS for degraded situation. |
|
Applicable |
Y/N/NYA |
|
Y in case when for parameter 1.1.1.3.10.1 was selected ‘none’. |
|
|
Can be repeated |
N |
|
Data presentation |
Single selection from predefined list: None ALSN ASFA ATB First generation ATB new generation ATC v2 ATC vR ATP ATP-VR/RHK BACC CAWS Chiltern-ATP Crocodile DAAT EBICAB 700 BU EBICAB 700 PT EBICAB 900 ES EuroSIGNUM EuroZUB EVM GNT (Geschwindigkeitsüberwachung für NeiTech-Züge) GW ATP INDUSI I60 KCVB KCVP KVB KVBP LS LZB (LZB L72, LZB L72 CE I and LZB L72 CE II) LZB ES Mechanical Trainstops |
|
|
MEMOR II+ NEXTEO PKP radio system with Radiostop function PZB 90 RETB RSDD/SCMT SHP SSC TBL 1 TBL 2 TBL1+ TPWS/AWS TVM 300 TVM 430 ZUB 123 |
|
Explanation on data presentation: Selected value shall answer the question whether any other system than ETCS exists on the respective track. |
|
|
References |
version 4.0 of the TD/2011-11 List of CCS Class B systems, |
|
|
|
|
Number |
1.1.1.3.11 |
|
Title |
Brake related parameters |
|
XML Name |
CBP |
|
Can be repeated |
N |
|
|
|
|
Number |
1.1.1.3.11.1 |
|
Title |
Maximum braking distance requested |
|
XML Name |
SOL Track Parameter CBP_MaxBrakeDist |
|
Definition |
The maximum value of the braking distance [in metres] of a train shall be given for the maximum line speed. |
|
Applicable |
Y/NYA |
|
Can be repeated |
N |
|
Data presentation |
[NNNNN] |
|
Comments |
This distance corresponds to the smallest physical distance between signals of the section of line at V max, taking into account the effect of gradient, minus the value of the safety margin used by the IM The braking capability of a train allows it to respect this braking distance. Note that the OPE TSI provides for an exchange of detailed information between the infrastructure manager and the railway undertaking to ensure safe operation. |
|
|
|
|
References |
OPE TSI: 4.2.2.6 CCS TSI: 4.2.2 |
|
Number |
1.1.1.3.11.2 |
|
Title |
Availability by the IM of additional information |
|
XML Name |
SOL Track Parameter CBP_AddInfoAvailable |
|
Definition |
Availability by the IM of additional information as defined in 4.2.2.6.2 (2) Regulation XXX - OPE TSI |
|
Applicable |
Y/NYA |
|
Can be repeated |
N |
|
Data presentation |
Single selection from the predefined list: Y/N |
|
General explanations |
[See TSI OPE 4.2.2.6.2 (2)] |
|
Reference |
[See TSI OPE 4.2.2.6.2 (2)] |
|
Validation |
|
|
|
|
|
Number |
1.1.1.3.11.3 |
|
Title |
Documents available by the IM relating to braking performance |
|
XML Name |
SOL Track Parameter CBP_BrakePerfDocRef |
|
Definition |
Electronic document available in two EU languages from the IM stored by the Agency providing additional information as defined in point (2) of point 4.2.2.6.2 of the Annex to Regulation XXX - OPE TSI |
|
Applicable |
Y/N/NYA Y in case of Y for 1.1.1.3.11.2 |
|
Can be repeated |
Y |
|
Data presentation |
CharacterString |
|
General explanations |
The infrastructure manager should have submitted such document to the Agency in an electronic format and in two EU languages. The document itself has to be upload by the NRE via the “reference document management” functionality. The reference of the document is provided for the parameter using the characterstring format. |
|
Reference |
|
|
Validation |
|
|
|
|
|
|
|
|
Number |
1.1.1.4 |
|
Title |
Rules and restrictions |
|
XML Name |
RUL |
|
Can be repeated |
N |
|
|
|
|
Number |
1.1.1.4.1 |
|
Title |
Existence of rules and restrictions of a strictly local nature |
|
XML Name |
SOL Track Parameter RUL_LocalRulesOrRestrictions |
|
Definition |
Existence of rules and restrictions of a strictly local nature |
|
Applicable |
Y/N/NYA |
|
Can be repeated |
N |
|
Data presentation |
Single selection from the predefined list: Y/N "In case of Y, the RU have to contact the IM to be informed of these conditions" |
|
General explanations |
There is a general obligation for Member States to notify existing national rules but: “Member States may decide not to notify rules and restrictions of a strictly local nature. In such cases, Member States shall mention those rules and restrictions in the registers of infrastructure.” In this eventuality, this parameter allows the IM accordingly to its Member State decision to declare the existence of such rules and to provide them with the parameter 1.1.1.4.2. Documents regarding the rules or restrictions of a strictly local nature available by the IM. |
|
Reference |
IOD: Notification of national rules Art 14. 11: |
|
Validation |
|
|
|
|
|
|
|
|
|
|
|
Number |
1.1.1.4.2 |
|
Title |
Documents regarding the rules or restrictions of a strictly local nature available by the IM |
|
XML Name |
SOL Track Parameter RUL_LocalRulesOrRestrictionsDocRef |
|
Definition |
Electronic document available from the IM stored by the Agency providing additional information |
|
Applicable |
Y/N/NYA |
|
Can be repeated |
Y |
|
Data presentation |
CharacterString |
|
General explanations |
The document itself has to be upload by the NRE via the “reference document management” functionality. The reference of the document is provided for the parameter using the characterstring format. |
|
Reference |
IOD: Notification of national rules Art 14. 11. Member States may decide not to notify rules and restrictions of a strictly local nature. In such cases, Member States shall mention those rules and restrictions in the registers of infrastructure referred to in Article 49 |
|
Validation |
|
|
|
|
|
|
|
|
Number |
1.2 |
|
Title |
OPERATIONAL POINT |
|
Can be repeated |
Y |
|
Explanation on repeatability: It means that many Operational Points within MS may be described – depending on the number of OPs in MS - and for each of them the whole set of data has to be filled. OPs do not have to be numbered as identification is done by OP IDs. |
|
Number |
1.2.0.0.0 |
|
|
Generic information |
|
Can be repeated |
N |
|
|
|
|
Number |
1.2.0.0.0.1 |
|
Title |
Name of Operational Point |
|
XML Name |
OPName |
|
Definition |
Name normally related to the town or village or to traffic control purpose |
|
Explanation on Definition |
Name of OP may not always exist in common use. In such case IM should propose a name for OP. |
|
Can be repeated |
N |
|
Applicable |
Y |
|
Data presentation |
CharacterString |
|
|
|
|
Number |
1.2.0.0.0.2 |
|
Title |
Unique OP ID |
|
XML Name |
UniqueOPID |
|
Definition |
Code composed of country code and alphanumeric OP code. |
|
Explanations on definition |
The first part ‘AA’ is the country code in two-letter system of ISO. The second part is alphanumeric OP code within the MS. For example, an OP code could be current abbreviation of name used in route books. In case of borders point, the code is to be selected in the corresponding list in annex 5.1. |
|
Applicable |
Y |
|
Can be repeated |
N |
|
Data presentation |
Predefined CharacterString: [AA+AAAAAAAAAA] |
|
Explanation on data presentation: The first two characters represent the country code in two-letter system of ISO. The second part ‘AAAAAAAAAA’ is maximum 10 Characters String corresponding to OP code within the MS. 'LUAB4' or 'LUAB46TH-G' or 'LUAB4/-_ERT7' are accepted by the validation process. In case of “borders point”, the code is to be selected in the corresponding list in annex 5.1 (this first part “AA” is EU. The second part is ‘AAAAAAAAAA’). Any OP ID that is not referenced in the annex 5.1 will not be accepted by the validation process. In case of “domestic borders point”, the code will be selected in the corresponding list in annex 5.2 that will be developed later. Any OP ID that is not referenced in the annex 5.1 will not be accepted by the validation process |
|
|
Validation |
The provided OP ID must be unique within each Member State. The validation has to be made nationally by NRE. The exceptions are “Border point” and “domestic border point” that must be referenced in annex 5.1. |
|
Reference |
ISO 3166-1 alpha 2 |
|
Number |
1.2.0.0.0.3 |
|
Title |
OP TAF TAP primary code |
|
XML Name |
OPTafTapCode |
|
Definition |
Primary code developed for TAF/TAP. |
|
Can be repeated |
Y |
|
Explanation on repeatability: Unique OP ID may cover area which is described by several TAF TAP Codes, so as in such case all those Primary Codes have to specified, the parameter 1.2.0.0.0.3 has to be repeated for every Primary Code. |
|
|
Applicable |
Y/N/NYA |
|
Y in case when OP TAF TAP primary code exists, otherwise N |
|
|
Data presentation |
Predefined CharacterString: [AANNNNN] |
|
Reference |
Primary code developed for TAF TSI by SEDP as given in CEN CWA15541:May2006. It is composed of two letters for the Country Code and five numbers for the Location Code. |
|
|
|
|
Number |
1.2.0.0.0.4 |
|
Title |
Type of Operational Point |
|
XMLName |
OPType |
|
Definition |
Type of facility in relation to the dominating operational functions. |
|
Explanations on definition |
Each existing case has to be approximated to the one of the above defined types by including size, importance and dominating functions. It is most important to recognize the most important role of specific OP in the network. That is why only one type for one OP is permitted. |
|
Applicable |
Y |
|
Can be repeated |
N |
|
Data presentation |
Single selection from the predefined list: station small station passenger terminal freight terminal depot or workshop train technical services passenger stop junction border point shunting yard technical change switch private siding domestic border point |
|
Explanations to format |
For purpose of RINF, there were defined the following types of OPs: |
Station – big or huge station with several functions, important for international traffic, basic for national railway system
Small station – multifunctional OP not so big and not so important like “station”
|
|
12: Switch 13: Private siding – OP allowing to provide more information on the “private siding” and on the way it is linked to the main network. Its use is left to the discretion of each Member State. 14: Domestic border point: located exactly in the point where networks of different IMs are connected in a Member State |
|
|
|
|
Number |
1.2.0.0.0.4.1 |
|
Title |
Type of track gauge changeover facility |
|
XMLName |
OPTypeGaugeChangeover |
|
Definition |
Type of track gauge changeover facility |
|
Explanations on definition |
|
|
Applicable |
Y/N/NYA |
|
Can be repeated |
N |
|
Data presentation |
Characterstring |
|
Explanations to format |
|
|
|
|
|
Number |
1.2.0.0.0.5 |
|
Title |
Geographical location of Operational Point |
|
XML Name |
OPGeographicLocation |
|
Definition |
Geographical coordinates in decimal degrees normally given for the centre of the OP. |
|
Applicable |
Y |
|
Can be repeated |
N |
Passenger terminal – OP with dominating function of service for passenger traffic
Freight terminal – OP with dominating functions related to loading and unloading of freight trains
Depot or workshop – OP which is a group of tracks used by depot or workshop for rolling stock maintenance
Train technical services – OP which is a group of tracks for servicing trains (parking, cleaning, washing, current revisions, etc.)
Passenger stop – small OP consisting of at least one platform, normally serving mostly for local passenger services
Junction – OP consisting of at least one turnout, normally used mostly for changing direction of trains, with reduced or not existing other functions
Border point – located exactly in the point where a border between MSs meets a railway line.
Shunting yard – group of tracks used for shunting trains, mostly related to freight trains
Technical change – to describe a change on CCS or a type of contact line or gauge changeover facility – fixed installation allowing a train to travel across a break of gauge where two railway networks with different track gauges meet.
|
Data presentation |
[Latitude (NN.NNNNNNN) + Longitude (±NN.NNNNNNN) |
|
Explanation on data presentation: Geographical coordinates according to the standard World Geodetic System (WGS) defining the location of the OP. This will normally be in the centre point of the OP. Values for coordinates are in degrees with decimals precision of 0.0001. |
|
|
Comments |
Latitude and Longitude are expressed in the WGS-grid for GPS-coordinates. |
|
|
|
|
Number |
1.2.0.0.0.6 |
|
Title |
Railway location of Operational Point |
|
XML Name |
OPRailwayLocation |
|
Definition |
Kilometre related to line identification defining the location of the OP. This will normally be in the centre of the OP. |
|
Explanation on Definition |
The railway location identifies the location of an OP in the system of reference of a given line. The parameter can be repeated to allow to describe the location of the OP when it belongs to several lines. |
|
Applicable |
Y |
|
Can be repeated |
Y |
|
Data presentation |
Predefined CharacterString: [±NNNN.NNN] + [CharacterString] |
|
Explanation on data presentation: The location (generally the distance from the origin of the line to the centre) on a line is given in kilometres with decimals (precision of 0.001). The aim of the "CharacterString" at the end of the format has to precise the name or number of the line. The same ‘CharacterString’ has to be used as ‘National line identification’ for a specific line in description both all OPs and all SoL. In [CharacterString] the name of the line shall be used the same type like in SoL description in parameter 1.1.0.0.0.2 National line identification. |
|
|
|
|
|
Number |
1.2.1 |
|
Title |
RUNNING TRACK |
|
XML Name |
OPTrack |
|
Can be repeated |
Y |
|
Explanation on repeatability: There might be more than one track within the Operational Point, so then the whole set of data for track has to be repeated as many times as many tracks exists. |
|
|
Applicable |
Parameters of this group (from 1.2.1.0.0.1 to 1.2.1.0.4.1) are only applicable if running tracks exist in the OP. |
|
|
|
|
Number |
1.2.1.0.0 |
|
Title |
Generic information |
|
Can be repeated |
N |
|
Explanation on repeatability: |
|
|
|
For each track may exist only one set of ‘Generic information’ |
|
|
|
|
Number |
1.2.1.0.0.1 |
|
Title |
IM’s Code |
|
XML Name |
OPTrackIMCode |
|
Definition |
Infrastructure Manager means any body or undertaking that is responsible in particular for establishing and maintaining railway infrastructure or a part thereof. |
|
Applicable |
Y |
|
Can be repeated |
N |
|
Data presentation |
[AAAA] |
|
General Explanations |
The Code is a unique identifier for the Infrastructure Manager and it shall be verified on national level. Each Section of Line may concern only one IM. |
|
Reference |
Article 3 (2) of Directive 2012/34/EU |
|
Validation |
No verification by RINF application. Check of the link between MS and IM’ Name must be done nationally. |
|
|
|
|
Number |
1.2.1.0.0.2 |
|
Title |
Identification of track |
|
XML Name |
OPTrackIdentification |
|
Definition |
Unique track identification or unique number within OP |
|
Applicable |
Y |
|
Can be repeated |
N |
|
Explanation on repeatability: Each track shall have unique identification or number within the OP. This number cannot be used for naming any other track in the same OP. |
|
|
Data presentation |
CharacterString |
|
Validation |
The check of fact that ID is unique within OP has to be done on national level (preferably by IM). |
|
|
|
|
Number |
1.2.1.0.1 |
|
Title |
Declarations of verification for track |
|
XML Name |
IDE |
|
Applicable |
Y |
|
Can be repeated |
N |
|
General Explanations |
This group of data concerns infrastructure subsystem on the specific track. |
If the IM is subject to TAF/TAP TSIs, it corresponds to the code used in TAF/TAP TSIs.
In other cases, it corresponds to the "organisation code” assigned by the Agency for the specific needs of the RINF
|
|
There are two types of declarations included: EC declaration issued according to mandatory procedure defined by Interoperability Directive and EI declaration which may be issued according to the voluntary procedure defined by EC Recommendation [22]. |
|
|
|
|
Number |
1.2.1.0.1.1 |
|
Title |
EC declaration of verification for track (INF) |
|
XML Name |
OP Track Parameter IDE_ECVerification |
|
Definition |
Unique number for EC declarations following format requirements specified in the ‘Document about practical arrangements for transmitting interoperability documents’ |
|
Explanation on Definition |
(INF) in the title means that here we include only declarations concerning infrastructure subsystem on the specific track. |
|
Applicable |
Y/N/NYA |
|
Explanation on applicability: “Y” shall be selected in case when EC declaration was issued |
|
|
Can be repeated |
Y |
|
Explanation on repeatability: The parameter may be repeated only when several EC declarations were issued after verification of the track and several numbers has to be registered. |
|
|
Data presentation |
Predefined CharacterString: [CC/RRRRRRRRRRRRRR/YYYY/NNNNNN] |
|
General Explanations |
With the extension of scope according to Interoperability Directive 2008/57/EC, geographical scope of the INF TSI now includes all the networks (TEN and off-TEN) with the following nominal track gauges: 1435, 1520, 1524, 1600 and 1668 mm |
|
Reference concerning format |
‘Document about practical arrangements for transmitting interoperability documents' [23] |
|
Validation |
The validation is described before this Table, in section 2.3. |
|
|
|
|
Number |
1.2.1.0.1.2 |
|
Title |
EI declaration of demonstration for track (INF) |
|
XML Name |
OP Track Parameter IDE_EIDemonstration |
|
Definition |
Unique number for EI declarations following the same format requirements as specified in the ‘Document about practical arrangements for transmitting interoperability documents’ |
|
Applicable |
Y/N/NYA |
|
Explanation on applicability: “Y” shall be selected in case when the demonstration was executed and EI declaration was issued. |
|
|
Can be repeated |
Y |
|
Explanation on repeatability: It may happen that several EI declarations were issued – then parameter has to be repeated as many times as many declarations were issued. |
|
|
Data presentation |
Predefined CharacterString: [CC/RRRRRRRRRRRRRR/YYYY/NNNNNN]) |
|
General Explanations |
It may happen that several EI declarations were issued – then parameter has to be repeated as many times as many declarations were issued. The procedure for demonstration that existing network fits to requirements of the TSIs is executed on voluntary bases, so when EI declaration do not exist then the parameter is optional. If EI declaration was not issued, then field shall be left empty. |
|
References |
documents' |
|
|
|
|
Number |
1.2.1.0.2 |
|
Title |
Performance parameters |
|
XML Name |
IPP |
|
Can be repeated |
N |
|
Explanation |
For each track only the one set of ‘Performance parameters‘ may be presented |
|
|
|
|
Number |
1.2.1.0.2.1 |
|
Title |
TEN classification of track |
|
XML Name |
OP Track Parameter IPP_TENClass |
|
Definition |
Indication of the part of the trans-European network the track belongs to |
|
Applicable |
Y/NYA |
|
Can be repeated |
Y |
|
Data presentation |
Single selection from the predefined list: Part of the TEN-T Comprehensive Network Part of the TEN-T Core Freight Network Part of the TEN-T Core Passenger Network Off-TEN |
|
Reference |
[24] Regulation (EU) No 1315/2013 |
|
|
|
|
Number |
1.2.1.0.2.2 |
|
Title |
Category of Line |
|
XML Name |
OP Track Parameter IPP_LineCat |
|
Definition |
Classification of a line according to the INF TSI |
|
Explanations on definition |
INF TSI classifies lines based on the type of traffic (traffic code). |
Recommendation 2014/881/EU
‘Document about practical arrangements for transmitting interoperability
|
|
TSI categories of line shall be used for the classification of existing lines to define a target system so that the relevant performance parameters will be met. |
|
Can be repeated |
Y Explanation on repeatability: When more than one value of the parameter has to be published, then parameter has to be repeated as many times as many values of the parameter will be published. |
|
Applicable |
Y/N/NYA |
|
Explanation on applicability: Technical scope of the INF TSI now includes all the networks (TEN and off-TEN) for nominal track gauges 1435, 1520, 1524, 1600 and 1668 mm Applicable if track is included in technical scope of the TSI. Not applicable when tables 2 or 3 of 4.2.1(7) of INF TSI are not usable on the UK network for Great Britain according to the specific case 7.7.17.1(2). |
|
|
Data presentation |
Single selection of the predefined list Passengers: P1 P2 P3 P4 P5 P6 P1520 P1600 Freight: F1 F2 F3 F4 F1520 F1600 |
|
Explanation on data presentation: The TSI category of line is a combination of traffic codes. For lines where only one type of traffic is carried (for example a freight only line), a single code can be used to describe the requirements; where mixed traffic runs the category will be described by one or more codes for passenger and freight in case of two types of traffic. Then the parameter is repeated if relevant. The combined traffic codes describe the envelope within which the desired mix of traffic can be accommodated. |
|
|
Example |
If a line is operated by passenger trains with speed of 250 km/h, local commuter trains with speed of 120 km/h and heavy freight trains in the night, then the best combination of traffic codes seems to be P2, P5 and F1. |
|
|
Then, the TSI category of line for this case would simply be P2-P5-F1. |
|
References |
INF TSI 4.2.1 |
|
|
|
|
Number |
1.2.1.0.2.3 |
|
Title |
Part of a Railway Freight Corridor |
|
XML Name |
OP Track Parameter IPP_FreightCorridor |
|
Definition |
Indication whether the line is designated to a Railway Freight Corridor |
|
Applicable |
Y/N/NYA |
|
Y if the line is part of a RFC |
|
|
Can be repeated |
Y |
|
Data presentation |
Single selection from the predefined list: Rhine-Alpine RFC (RFC 1) North Sea-Mediterranean RFC (RFC 2) Scandinavian – Mediterranean RFC (RFC 3) Atlantic RFC (RFC 4) Baltic-Adriatic RFC (RFC 5) Mediterranean RFC (RFC 6) Orient-EastMed RFC (RFC 7) North Sea-Baltic RFC (RFC 8) Rhine-Danube RFC (RFC 9) Alpine-Western Balkan RFC (RFC 10) Amber RFC (RFC 11) |
|
Explanation on data presentation: If a line belongs to several corridors, repeat the parameter |
|
|
Reference |
Regulation (EU) No 913/2010 |
|
|
|
|
Number |
1.2.1.0.3 |
|
Title |
Line layout |
|
XML Name |
ILL |
|
Can be repeated |
N |
|
Explanations |
For specific track only one line layout may be described |
|
|
|
|
Number |
1.2.1.0.3.4 |
|
Title |
Gauging |
|
XML Name |
SOL OP Track Parameter ILL_Gauging |
|
Definition |
Gauges as defined in European standard or other local gauges, including lower or upper part. |
|
Can be repeated |
Y |
|
Explanation on definition |
|
|
Applicable |
Y/NYA |
|
Data presentation |
Single selection from the predefined list: GA GB GC G1 DE3 G2 GB1 GB2 BE1 BE2 BE3 FR-3.3 PTb PTb+ PTc FIN1 SEa SEc DE1 DE2 Z-GCD UK1 UK1[D] W6 FS S GHE16 GEA16 GEB16 GEC16 IRL1 IRL2 IRL3 GI1 GI2 GI3 GEE10 GED10 AFM 423 NL1 NL2 FR-3.4.1 FR-3.4.2 AFG AFM425 AFM427 M30 M80 Tram-train 2.40 Tram-train 2.65 Métrique BA Métrique SGV Métrique Cerd. GB:GČD GCZ3 |
|
|
GČD GEI1 GEI2 GEI3 GEC14 EBV1 EBV2_reduziert EBV2 EBV3_reduziert EBV3 EBV4 other |
|
References |
EN15273-3 (2013): Annex C and Annex D INF TSI: 4.2.3.1 It is proposed to update the reference to EN 15273-3 (2013): Annex C taking into account corrigendum A1 |
|
|
|
|
|
|
|
Number |
1.2.1.0.3.5 |
|
Title |
Railway location of particular points requiring specific checks |
|
XML Name |
ILL_GaugeCheckLoc |
|
Explanation on Definition |
Location of particular points requiring specific checks due to deviations from gauging referred to in 1.2.1.0.3.4. |
|
Explanations of the definition |
The railway location identifies the location of the structure in the system of reference of the line to which the track belongs |
|
Applicable |
Y/N/NYA |
|
Can be repeated |
N |
|
Data presentation |
Predefined CharacterString: [±NNNN.NNN] + [CharacterString] |
|
Explanation on data presentation: The location (generally the distance from the origin of the line to the centre) on a line is given in kilometres with decimals (precision of 0.001). The aim of the "CharacterString" at the end of the format has to precise the name or number of the line. The same ‘CharacterString’ has to be used as ‘National line identification’ for a specific line in description both all OPs and all SoL. This parameter could be also applicable when the gauge is infringed. This means that the obstacles are inside the infrastructure gauge. This case could happen for example for platforms where the platform does not fulfill the gauge. In [CharacterString] the name of the line shall be used the same type like in SoL description in parameter 1.1.0.0.0.2 National line identification. |
|
|
References |
|
|
|
|
|
|
|
|
Number |
1.2.1.0.3.6 |
|
Title |
Document with the transversal section of the particular points requiring specific checks |
|
XML Name |
ILL_GaugeCheckDocRef |
|
Definition |
Electronic document available from the IM stored by the Agency with the transversal section of the particular points requiring specific checks due to deviations from gauging referred to in 1.2.1.0.3.4. Where relevant, guidance for the check with the particular point may be attached to the document with the transversal section. |
|
Applicable |
Y/N/NYA |
|
Can be repeated |
Y |
|
Data presentation |
CharacterString |
|
Explanation |
The document itself has to be upload by the NRE via the “reference document management” functionality. The reference of the document is provided for the parameter using the characterstring format. |
|
References |
EN 50125-1 (1999): 4.7 and 4.8 LOC&PAS TSI: 4.2.6.1.2 |
|
|
|
|
|
|
|
|
|
|
Number |
1.2.1.0.4 |
|
Title |
Track parameters |
|
XML Name |
ITP |
|
Can be repeated |
N |
|
|
|
|
Number |
1.2.1.0.4.1 |
|
Title |
Nominal track gauge |
|
XML Name |
OP Track Parameter ITP_NomGauge |
|
Definition |
A single value expressed in millimetres that identifies the track gauge |
|
Can be repeated |
Y |
|
Explanation on repeatability: When in the track has been installed a track gauge changeover without having OP type ‘Technical change’, the value of nominal track gauge has to be given twice, for each track gauge separately. |
|
|
Applicable |
Y/NYA |
|
Data presentation |
Single selection from the predefined list: 750 1000 1435 1520 1524 1600 1668 other |
|
General Explanations |
In case of multi-rail track, a set of data is to be published separately to each pair of rails to be operated as separate track (the whole set of parameters for the separate track has to be delivered – be careful then with the track identification). |
|
Reference |
INF TSI 4.2.4.1 |
|
|
|
|
Number |
1.2.1.0.5 |
|
Title |
Tunnel |
|
XML Name |
OPTrackTunnel |
|
Applicable |
Parameters of this group (from 1.2.1.0.5.1 to 1.2.1.0.5.8) are only applicable if tunnels exist in the OP. |
|
Can be repeated |
Y |
|
|
|
|
Number |
1.2.1.0.5.1 |
|
Title |
IM’s Code |
|
XML Name |
OPTrackTunnelIMCode |
|
Definition |
Infrastructure Manager means any body or undertaking that is responsible in particular for establishing and maintaining railway infrastructure or a part thereof. |
|
Applicable |
Y |
|
Can be repeated |
N |
|
Data presentation |
[AAAA] |
|
General Explanations |
The Code is a unique identifier for the Infrastructure Manager and it shall be verified on national level. Each Section of Line may concern only one IM. |
|
Reference |
Article 3 (2) of Directive 2012/34/EU |
|
Validation |
No verification by RINF application. Check of the link between MS and IM’ Name must be done nationally. |
|
|
|
If the IM is subject to TAF/TAP TSIs, it corresponds to the code used in TAF/TAP TSIs.
In other cases, it corresponds to the "organisation code” assigned by the Agency for the specific needs of the RINF
|
Number |
1.2.1.0.5.2 |
|
Title |
Tunnel identification |
|
XML Name |
OPTrackTunnelIdentification |
|
Definition |
Unique tunnel identification or unique number within Member State |
|
Can be repeated |
N |
|
Applicable |
Y |
|
In case when tunnel does not have own identification within the Member State, the IM should deliver it himself. |
|
|
Data presentation |
CharacterString |
|
Comments |
Here should be given the name, number, code or any other expression which is normally used for the identification of the tunnel |
|
Number |
1.2.1.0.5.3 |
|
Title |
EC declaration of verification for tunnel (SRT) |
|
XML Name |
OP Track Tunnel Parameter ITU_ECVerification |
|
Definition |
Unique number for EC declarations following format requirements specified in the ‘Document about practical arrangements for transmitting interoperability documents’ |
|
Can be repeated |
Y |
|
Explanation on repeatability: (SRT) in title means that here we include only declarations concerning requirements of SRT TSI for infrastructure system on the specific track. Parameter shall be repeated when different EC declarations were issued for different elements of infrastructure subsystem on the specific track in the tunnel. |
|
|
Applicable |
Y/N/NYA |
|
Explanation on applicability: “Y” shall be selected in case when EC declaration was issued |
|
|
Data presentation |
Predefined CharacterString: [CC/RRRRRRRRRRRRRR/YYYY/NNNNNN] |
|
General Explanations |
With the extension of scope according to Interoperability Directive 2008/57/EC, geographical scope of the INF, ENE and CCS TSIs now includes all the networks (TEN and off-TEN) with the following nominal track gauges: 1435, 1520, 1524, 1600 and 1668 mm. |
|
Reference concerning format |
‘Document about practical arrangements for transmitting interoperability documents' [23] |
|
Validation |
The validation is described before this Table, in section 2.3. |
|
|
|
|
Number |
1.2.1.0.5.4 |
|
Title |
EI declaration of demonstration for tunnel (SRT) |
|
XML Name |
OP Track Tunnel Parameter ITU_EIDemonstration |
|
Definition |
Unique number for EI declarations following the same format requirements as specified in the ‘Document about practical arrangements for transmitting interoperability documents’ |
|
Can be repeated |
Y |
|
Explanation on repeatability: (SRT) in title means that here we include only declarations concerning requirements of SRT TSI for infrastructure system on the specific track. Parameter shall be repeated when different EI declarations were issued for different elements of infrastructure subsystem on the specific track in the tunnel. |
|
|
Applicable |
Y/N/NYA |
|
Explanation on applicability: “Y” shall be selected in case when the demonstration was executed and EI declaration was issued. |
|
|
Data presentation |
Predefined CharacterString: [CC/RRRRRRRRRRRRRR/YYYY/NNNNNN]) |
|
General Explanations |
It may happen that several EI declarations were issued – then parameter has to be repeated as many times as many declarations were issued. The procedure for demonstration that existing network fits to requirements of the TSIs is executed on voluntary bases, so when EI declaration do not exist then the parameter is optional. If EI declaration was not issued, then field shall be left empty. |
|
Reference |
documents' |
|
Validation |
The validation is described before this Table, in section 2.3. |
|
|
|
|
Number |
1.2.1.0.5.5 |
|
Title |
Length of tunnel |
|
XML Name |
OP Track Tunnel Parameter ITU_Length |
|
Definition |
Length of a tunnel in metres from entrance portal to exit portal. |
|
Explanations on definition |
Length of a tunnel in metres from portal to portal at the level of the top of rail. |
|
Can be repeated |
N |
|
Applicable |
Y/N/NYA |
|
Y only for a tunnel with length of 100 metres or more. |
|
|
Data presentation |
Predefined CharacterString: [NNNNN] |
|
Validation |
The validation whether the parameter is mandatory cannot be performed by the RINF application, the validation has to be done by the NRE. |
|
|
|
Recommendation 2014/881/EU
‘Document about practical arrangements for transmitting interoperability
|
Number |
1.2.1.0.5.6 |
|
Title |
Existence of emergency plan |
|
XML Name |
OP Track Tunnel Parameter ITU_EmergencyPlan |
|
Definition |
Indication whether emergency plan exists. |
|
Can be repeated |
N |
|
Applicable |
Y/N/NYA |
|
Explanation on applicability: Y for tunnels longer than 1 km, in accordance with section 4.4.2 of SRT TSI, the emergency plan is mandatory only for tunnel length of more than 1km. ‘N’=not applicable can be selected for short tunnels of less than 1 km, as for them the fire category according SRT TSI does not exist. |
|
|
Data presentation |
Single selection from the predefined list: Y N |
|
General Explanations |
Emergency plan has to be a document developed for each tunnel under the direction of the IM, in co-operation, where appropriate, with RUs, Rescue services and relevant authorities. It shall be consistent with the self-rescue, evacuation and rescue facilities provided. |
|
References |
SRT TSI: 4.4.3 SRT TSI: 4.4.2 |
|
Number |
1.2.1.0.5.7 |
|
Title |
Fire category of rolling stock required |
|
XML Name |
OP Track Tunnel Parameter ITU_FireCatReq |
|
Definition |
Categorisation how a passenger train with a fire on board will continue to operate for a defined time period. |
|
Can be repeated |
N |
|
Applicable |
Y/N/NYA |
|
Explanation on applicability: ‘N’=not applicable shall be selected for short tunnels of less than 1 km, as for them the fire category according SRT TSI does not exist. |
|
|
Data presentation |
Single selection from the predefined list: A B none |
|
Explanation on data presentation: Wherever category B is not needed, generally the category A has to be understood as the default value. ‘none’ shall be selected when none of A or B fire category is applied for a specific tunnel. |
|
|
References |
SRT: section 4.2.3.3.4 SRT TSI: 4.2.5.5 LOC&PAS 4.2.10.4.4 |
|
|
|
|
Number |
1.2.1.0.5.8 |
|
Title |
National fire category of rolling stock required |
|
XML Name |
OP Track Tunnel Parameter ITU_NatFireCatReq |
|
Definition |
Categorisation on how a passenger train with a fire on board will continue to operate for a defined time period - according to national rules if they exist. |
|
Can be repeated |
N |
|
Applicable |
Y/N/NYA |
|
Explanation on applicability: ‘N’=not applicable shall be selected when respective national rules do not exist Y only for tunnels when for the parameter 1.2.1.0.5.7 the option ‘none’ was selected. |
|
|
Data presentation |
CharacterString |
|
Explanation on data presentation: |
|
|
|
Data shall include both the category and brief name of the document introducing the categorisation |
|
|
|
|
Number |
1.2.1.0.5.9 |
|
Title |
Diesel or other thermal traction allowed |
|
XML Name |
OP Track Tunnel Parameter ITU_DieselThermAllowed |
|
Definition |
Indication whether it is allowed to use diesel or other thermal traction in the tunnel |
|
Can be repeated |
N |
|
Applicable |
Y/N/ |
|
Explanation on applicability: ‘N’= not applicable shall be selected when respective national rules do not exist ‘Y’= only for tunnels when for the parameter 1.2.1.0.5.7 the option ‘none’ was selected. |
|
|
Data presentation |
Single selection from the predefined list: Y / N |
|
Explanation on data presentation: |
|
|
|
|
|
|
|
|
Number |
1.2.1.0.6 |
|
Title |
Platform |
|
XML Name |
OPTrackPlatform |
|
Applicable |
Parameters of this group (from 1.2.1.0.6.1 to 1.2.1.0.6.7) are only applicable if platforms exist on the OP |
|
Can be repeated |
Y |
|
|
|
|
Number |
1.2.1.0.6.1 |
|
Title |
IM’s Code |
|
XML Name |
OPTrackPlatformIMCode |
|
Definition |
Infrastructure Manager means any body or undertaking that is responsible in particular for establishing and maintaining railway infrastructure or a part thereof. |
|
Can be repeated |
N |
|
Applicable |
Y |
|
Data presentation |
[AAAA] |
|
General Explanations |
The Code is a unique identifier for the Infrastructure Manager and it shall be verified on national level. Each Section of Line may concern only one IM. |
|
Reference |
Article 3 (2) of Directive 2012/34/EU |
If the IM is subject to TAF/TAP TSIs, it corresponds to the code used in TAF/TAP TSIs.
In other cases, it corresponds to the "organisation code” assigned by the Agency for the specific needs of the RINF
|
Validation |
No verification by RINF application. Check of the link between MS and IM’ Name must be done nationally. |
|
|
|
|
Number |
1.2.1.0.6.2 |
|
Title |
Identification of platform |
|
XML Name |
OPTrackPlatformIdentification |
|
Definition |
Unique platform identification or unique platform number within OP |
|
Can be repeated |
N |
|
Applicable |
Y |
|
Data presentation |
CharacterString |
|
General Explanations |
Platform for the purpose of RINF is understood as a platform edge. Platform identification shall concern only the part of the structure neighbouring to the track (interfaced with trains). In case when normal platform numbering concern the whole structure between two tracks, the “RINF track” may be labelled with the identification made of platform number and the track ID to which the specific edge belongs. Other solutions for the identification of the platform as the edge adopted by IM or MS are also permitted. |
|
|
|
|
Number |
1.2.1.0.6.3 |
|
Title |
TEN Classification of platform |
|
XML Name |
OP Track Platform Parameter IPL_TENClass |
|
Definition |
Indicates the part of the trans-European network the platform belongs to. |
|
Can be repeated |
Y |
|
Applicable |
Y/ NYA |
|
Data presentation |
Single selection from the predefined list: Part of the TEN-T Comprehensive Network Part of the TEN-T Core Freight Network Part of the TEN-T Core Passenger Network Off-TEN |
|
Reference |
[24] Regulation (EU) No 1315/2013 |
|
|
|
|
Number |
1.2.1.0.6.4 |
|
Title |
Usable length of platform |
|
XML Name |
OP Track Platform Parameter IPL_Length |
|
Definition |
The maximum continuous length (expressed in metres) of that part of platform in front of which a train is intended to remain stationary in normal operating conditions for passengers to board and alight from the train, making appropriate allowance for stopping tolerances. |
|
Explanation on Definition |
The maximum continuous length (expressed in metres) of that part of platform in front of which a train is intended to remain stationary in normal operating conditions for passengers to board and alight from the train, making appropriate allowance for stopping tolerances |
|
Applicable |
Y/NYA |
|
Can be repeated |
N |
|
Data presentation |
[NNNN] |
|
Comments about problems in the definitions |
Platform dimensions are always related to one neighbouring track at a time. So, if two tracks are along a platform, this platform should be divided into two RINF platforms to have precise description of each. |
|
References |
INF TSI 4.2.10, OPE TSI: 2.3.6 and 2.3.7 of Appendix D |
|
|
|
|
Number |
1.2.1.0.6.5 |
|
Title |
Height of platform |
|
XML Name |
OP Track Platform Parameter IPL_Height |
|
Definition |
Distance between the upper surface of platform and running surface of the neighbouring track. It is the nominal value expressed in millimetres. |
|
Applicable |
Y/ NYA |
|
Can be repeated |
N |
|
Data presentation |
Single selection from the predefined list: 250 280 550 760 300-380 200 580 680 685 730 840 900 915 920 960 1100 other |
|
|
Explanation on data presentation: Values included in the list are taken from PRM and INF TSIs including Specific Cases. They are the values which are mandatory for the design of the platform at the respective part of the network. They are not real values measured at real platforms. |
|
Comment |
Platform dimensions are always related to one neighbouring track at a time. So, if two tracks are along a platform, this platform should be divided into two or more ‘RINF platforms’ to have precise description of each. |
|
References |
INF TSI 4.2.10.4 PRM TSI 4.1.8 and 4.1.2.18 OPE TSI: 2.3.8 of Appendix D |
|
Number |
1.2.1.0.6.6 |
|
Title |
Existence of platform assistance for starting train |
|
XML Name |
OP Track Platform Parameter IPL_AssistanceStartingTrain |
|
Definition |
Indication of existence of equipment or staff supporting the train crew in starting the train. |
|
Explanation on Definition |
Fixed equipment (for example mirrors or CCTV cameras) or station staff indicating to train crew or driver when to close doors and whether this has been done successfully. |
|
Applicable |
Y/NYA |
|
Can be repeated |
N |
|
Data presentation |
Single selection from the predefined list: Y N |
|
|
|
|
Number |
1.2.1.0.6.7 |
|
Title |
Range of use of the platform boarding aid |
|
XML Name |
OP Track Platform Parameter IPL_AreaBoardingAid |
|
Definition |
Information of the train access level for which the boarding aid can be used. |
|
Applicable |
Y/NYA |
|
Can be repeated |
N |
|
Data presentation |
[NNNN] |
|
|
Explanation on data presentation: Vertical difference that is overcome by the platform boarding aid in millimetres The value “0” means that the platform is not equipped with a platform boarding aid |
|
General Explanations |
This parameter is mandatory only if such a device exists. There is no check on the provision of the parameter in the verification process of the RINF application. |
|
References |
PRM TSI: 4.4.3 |
|
|
|
|
Number |
1.2.2 |
|
Title |
SIDING |
|
XML Name |
OPSiding |
|
Can be repeated |
Y |
|
Explanation on repeatability: The set of data for siding may be repeated as many times as many sidings within the same OP exist. |
|
|
Applicable |
Parameters of this group are only applicable (from 1.2.2.0.0.1 to 1.2.2.2.0.4.6) if sidings exist in the OP |
|
|
|
|
Number |
1.2.2.0.0 |
|
Title |
Generic information |
|
Can be repeated |
N |
|
Explanation on repeatability: For each siding it may exist only one set of ‘Generic information’ |
|
|
|
|
|
Number |
1.2.2.0.0.1 |
|
Title |
IM’s Code |
|
XML Name |
OPSidingIMCode |
|
Definition |
Infrastructure Manager means any body or undertaking that is responsible in particular for establishing and maintaining railway infrastructure or a part thereof. |
|
Applicable |
Y |
|
Can be repeated |
N |
|
Data presentation |
[NNNN] |
|
General Explanations |
Code shall correspond to the name of Infrastructure Manager and it shall be verified on national level. It should correspond to the code used in TAF/TAP TSIs to identify IMs. Each Section of Line may concern only one IM. |
|
Reference |
Article 3 (2) of Directive 2012/34/EU |
|
Validation |
No verification by RINF application. Check of the link between MS and IM’ Name must be done nationally. |
|
Number |
1.2.2.0.0.2 |
|
Title |
Identification of siding |
|
XML Name |
OPSidingIdentification |
|
Definition |
Unique siding identification or unique siding number within OP |
|
Can be repeated |
N |
|
Explanation on repeatability: Each track shall have unique identification or number within the OP. This number cannot be used for naming any other track in the same OP. |
|
|
Applicable |
Y |
|
Data presentation |
CharacterString |
|
Validation |
The check of fact that ID is unique within OP has to be done on national level (preferably by IM). |
|
|
|
|
Number |
1.2.2.0.0.3 |
|
Title |
TEN classification of siding |
|
XML Name |
OP Siding Parameter IPP_TENClass |
|
Definition |
Indication of the part of the trans-European network the siding belongs to. |
|
Can be repeated |
Y |
|
Applicable |
Y/NYA |
|
Data presentation |
Single selection from the predefined list: Part of the TEN-T Comprehensive Network Part of the TEN-T Core Freight Network Part of the TEN-T Core Passenger Network Off-TEN |
|
Reference |
[24] Regulation (EU) No 1315/2013 |
|
umber |
1.2.2.0.1 |
|
Title |
Declaration of verification for siding |
|
XML Name |
IDE |
|
Can be repeated |
N |
|
Explanation |
As RINF includes only INF parameters for OP, information on EC declaration concerns also only infrastructure subsystem verification |
|
|
|
|
Number |
1.2.2.0.1.1 |
|
Title |
EC declaration of verification for siding (INF) |
|
XML Name |
OP Siding Parameter IDE_ECVerification |
|
Definition |
Unique number for EC declarations following format requirements specified in the 'Document about practical arrangements for transmitting interoperability documents' |
|
Can be repeated |
Y |
|
Explanation on repeatability: (INF) in the title means that here we include only declarations concerning infrastructure subsystem on the specific siding. The parameter may be repeated only when several EC declarations were issued after verification of the siding and several numbers has to be registered. |
|
|
Applicable |
Y/N/NYA |
|
Explanation on applicability: “Y” shall be selected in case when EC declaration was issued |
|
|
Data presentation |
Predefined CharacterString: [CC/RRRRRRRRRRRRRR/YYYY/NNNNNN] |
|
General Explanations |
With the extension of scope according to Interoperability Directive 2008/57/EC, geographical scope of the INF TSI now includes all the networks (TEN and off-TEN) with the following nominal track gauges: 1435, 1520, 1524, 1600 and 1668 mm |
|
Reference concerning format |
‘Document about practical arrangements for transmitting interoperability documents' [23] |
|
Validation |
The validation is described before this Table, in section 2.3. |
|
Number |
1.2.2.0.1.2 |
|
Title |
EI declaration of demonstration for siding (INF) |
|
XML Name |
OP Siding Parameter IDE_EIDemonstration |
|
Definition |
Unique number for EI declarations following the same format requirements as specified in the ‘Document about practical arrangements for transmitting interoperability documents’ |
|
Can be repeated |
Y |
|
Applicable |
Y/N/NYA |
|
Explanation on applicability: “Y” shall be selected in case when the demonstration was executed and EI declaration was issued. |
|
|
Data presentation |
Predefined CharacterString: [CC/RRRRRRRRRRRRRR/YYYY/NNNNNN]) |
|
General Explanations |
It may happen that several EI declarations were issued – then parameter has to be repeated as many times as many declarations were issued. The procedure for demonstration that existing network fits to requirements of the TSIs is executed on voluntary bases, so when EI declaration do not exist then the parameter is optional. If EI declaration was not issued, then field shall be left empty. |
|
Reference |
documents' |
|
Validation |
The validation is described before this Table, in section 2.3. |
|
|
|
|
Number |
1.2.2.0.2 |
|
Title |
Performance parameter |
|
XML Name |
IPP |
|
Can be repeated |
N |
|
Explanation |
For each siding only the one set of ‘Performance parameters‘ may be presented |
|
Number |
1.2.2.0.2.1 |
|
Title |
Usable length of siding |
|
XML Name |
OP Siding Parameter IPP_Length |
|
Definition |
Total length of the siding/stabling track expressed in metres where trains can be parked safely. |
|
Applicable |
Y/NYA |
|
Can be repeated |
N |
|
Data presentation |
[NNNN] |
|
Explanation on data presentation: The value shall include operational rules for braking, position of vehicles not influencing the clearance of neighbouring tracks, etc. |
|
|
Reference |
INF TSI: 4.2.10.1. |
|
|
|
Recommendation 2014/881/EU
‘Document about practical arrangements for transmitting interoperability
|
Number |
1.2.2.0.3 |
|
Title |
Line layout |
|
XML Name |
ILL |
|
Can be repeated |
N |
|
|
|
|
Number |
1.2.2.0.3.1 |
|
Title |
Gradient for stabling tracks |
|
XML Name |
OP Siding Parameter ILL_Gradient |
|
Definition |
Maximum value of the gradient expressed in millimetres per metre. |
|
Applicable |
Y/N/NYA |
|
|
|
|
Can be repeated |
N |
|
Data presentation |
[NN.N] |
|
General Explanations |
It has to be shown the real value of the gradient when it exceeds the TSI limit of 2.5 expressed in millimetres per metre. |
|
Reference |
INF TSI: 4.2.4.3 (8) |
|
|
|
|
Number |
1.2.2.0.3.2 |
|
Title |
Minimum radius of horizontal curve |
|
XML Name |
OP Siding Parameter ILL_MinRadHorzCurve |
|
Definition |
Radius of the smallest horizontal curve expressed in metres. |
|
Applicable |
Y/N/NYA |
|
|
|
|
Can be repeated |
N |
|
Data presentation |
[NNN] |
|
General Explanations |
The real value of the radius (expressed in metres) has to be presented if it is below the minimum limit of 150 m given in CR INF TSI. |
|
References |
INF TSI: 4.2.3.4 |
|
|
|
|
Number |
1.2.2.0.3.3 |
|
Title |
Minimum radius of vertical curve |
|
XML Name |
OP Siding Parameter ILL_MinRadVertCurve |
|
Definition |
Radius of the smallest vertical curve expressed in metres |
|
Applicable |
Y/N/NYA |
|
|
|
|
Can be repeated |
N |
|
Data presentation |
Predefined CharacterString: [NNN+NNN] |
|
|
Explanation on data presentation: Here shall be presented the real values of the radius of vertical curve when at least one of the values in crest or in hollow is smaller than the minimum limit given in INF TSI. The first ‘NNN’ is a value of crest, second ‘NNN’ is a value of hollow, both expressed in metres, For the TSI compliant lines the default values of crest is 600 m, and for hollow is 900 m. For TSI compliant marshalling yards default values are: crest 250 m, hollow 300 m. |
|
References |
INF TSI: 4.2.3.4 |
|
|
|
|
Number |
1.2.2.0.4 |
|
Title |
Fixed installations for servicing trains |
|
XML Name |
ITS |
|
Can be repeated |
N |
|
|
|
|
Number |
1.2.2.0.4.1 |
|
Title |
Existence of toilet discharge |
|
XML Name |
OP Siding Parameter ITS_ToiletDischarge |
|
Definition |
Indication whether exists an installation for toilet discharge (fixed installation for servicing trains) as defined in INF TSIs. |
|
Applicable |
Y/NYA |
|
Can be repeated |
N |
|
Data presentation |
Single selection from the predefined list: Y N |
|
References |
INF TSI: 4.2.13.2 |
|
|
|
|
Number |
1.2.2.0.4.2 |
|
Title |
Existence of external cleaning facilities |
|
XML Name |
OP Siding Parameter ITS_ExternalCleaning |
|
Definition |
Indication whether exists an installation for external cleaning facility (fixed installation for servicing trains) as defined in INF TSIs. |
|
Applicable |
Y/NYA |
|
Can be repeated |
N |
|
Data presentation |
Single selection from the predefined list: Y N |
|
References |
INF TSI: 4.2.13.3. |
|
|
|
|
Number |
1.2.2.0.4.3 |
|
Title |
Existence of water restocking |
|
XML Name |
OP Siding Parameter ITS_WaterRestocking |
|
Definition |
Indication whether exists an installation for water restocking (fixed installation for servicing trains) as defined in INF TSIs. |
|
Applicable |
Y/NYA |
|
Can be repeated |
N |
|
Data presentation |
Single selection from the predefined list: Y N |
|
References |
INF TSI: 4.2.13.4. |
|
|
|
|
Number |
1.2.2.0.4.4 |
|
Title |
Existence of refuelling |
|
XML Name |
OP Siding Parameter ITS_Refuelling |
|
Definition |
Indication whether exists an installation for refuelling (fixed installation for servicing trains) as defined in INF TSIs. |
|
Applicable |
Y/NYA |
|
Can be repeated |
N |
|
Data presentation |
Single selection from the predefined list: Y N |
|
References |
INF TSI 4.2.13.5 |
|
|
|
|
Number |
1.2.2.0.4.5 |
|
Title |
Existence of sand restocking |
|
XML Name |
OP Siding Parameter ITS_SandRestocking |
|
Definition |
Indication whether an installation for sand restocking exists (fixed installation for servicing trains). |
|
Applicable |
Y/NYA |
|
Can be repeated |
N |
|
Data presentation |
Single selection from the predefined list: Y N |
|
Reference |
|
|
|
|
|
Number |
1.2.2.0.4.6 |
|
Title |
Existence of electric shore supply |
|
XML Name |
OP Siding Parameter ITS_ElectricShoreSupply |
|
Definition |
Indication whether an installation for electric shore supply exists (fixed installation for servicing trains). |
|
Applicable |
Y/NYA |
|
Can be repeated |
N |
|
Data presentation |
Single selection from the predefined list: Y N |
|
References |
INF TSI: 4.2.12.6 and 6.2.4.14 |
|
|
|
|
Number |
1.2.2.0.5 |
|
Title |
Tunnel |
|
XML Name |
OPSidingTunnel |
|
Applicable |
Parameters of this group (from 1.2.2.0.5.1 to 1.2.2.0.5.8) are only mandatory if tunnels exist on the siding on the OP |
|
Can be repeated |
Y |
|
|
|
|
Number |
1.2.2.0.5.1 |
|
Title |
IM’s Code |
|
XML Name |
OPSidingTunnelIMCode |
|
Definition |
Infrastructure Manager means any body or undertaking that is responsible in particular for establishing and maintaining railway infrastructure or a part thereof. |
|
Can be repeated |
N |
|
Applicable |
Y |
|
Data presentation |
[AAAA] |
|
General Explanations |
The Code is a unique identifier for the Infrastructure Manager and it shall be verified on national level. Each Section of Line may concern only one IM. |
|
Reference |
Article 3 (2) of Directive 2012/34/EU |
|
Validation |
No verification by RINF application. Check of the link between MS and IM’ Name must be done nationally. |
|
|
|
|
Number |
1.2.2.0.5.2 |
|
Title |
Tunnel identification |
|
XML Name |
OPSidingTunnelIdentification |
|
Definition |
Unique tunnel identification or unique number within Member State |
|
Applicable |
Y |
|
In case when tunnel does not have own identification within the Member State, the IM should deliver it himself. |
|
|
Can be repeated |
N |
|
Data presentation |
CharacterString |
|
Comments |
Here should be given the name, number, code or any other expression which is normally used for the identification of the tunnel. |
|
|
|
|
Number |
1.2.2.0.5.3 |
|
Title |
EC declaration of verification for tunnel (SRT) |
|
XML Name |
OP Siding Tunnel Parameter ITU_ECVerification |
|
Definition |
Unique number for EC declarations following format requirements specified in the ‘Document about practical arrangements for transmitting interoperability documents’ |
|
Can be repeated |
Y |
|
Explanation on repeatability: (SRT) in title means that here we include only declarations concerning requirements of SRT TSI for infrastructure system on the specific track. Parameter shall be repeated when different EC declarations were issued for different elements of infrastructure subsystem on the specific track in the tunnel. |
|
|
Applicable |
Y/N/NYA |
|
Explanation on applicability: “Y” shall be selected in case when EC declaration was issued |
|
|
Data presentation |
Predefined CharacterString: [CC/RRRRRRRRRRRRRR/YYYY/NNNNNN] |
|
General Explanations |
With the extension of scope according to Interoperability Directive 2008/57/EC, geographical scope of the INF, ENE and CCS TSIs now includes all the networks (TEN and off-TEN) with the following nominal track gauges: 1435, 1520, 1524, 1600 and 1668 mm |
If the IM is subject to TAF/TAP TSIs, it corresponds to the code used in TAF/TAP TSIs.
In other cases, it corresponds to the "organisation code” assigned by the Agency for the specific needs of the RINF
|
Reference concerning format |
‘Document about practical arrangements for transmitting interoperability documents' [23] |
|
Validation |
The validation is described before this Table, in section 2.3. |
|
|
|
|
Number |
1.2.2.0.5.4 |
|
Title |
EI declaration of demonstration for tunnel (SRT) |
|
XML Name |
OP Siding Tunnel Parameter ITU_EIDemonstration |
|
Definition |
Unique number for EI declarations following the same format requirements as specified in the ‘Document about practical arrangements for transmitting interoperability documents’ |
|
Can be repeated |
Y |
|
Explanation on repeatability: (SRT) in title means that here we include only declarations concerning requirements of SRT TSI for infrastructure system on the specific track. Parameter shall be repeated when different EI declarations were issued for different elements of infrastructure subsystem on the specific track in the tunnel. It may happen that several EI declarations were issued – then parameter has to be repeated as many times as many declarations were issued. |
|
|
Applicable |
Y/N/NYA |
|
Explanation on applicability: “Y” shall be selected in case when the demonstration was executed and EI declaration was issued |
|
|
General Explanations |
It may happen that several EI declarations were issued – then parameter has to be repeated as many times as many declarations were issued. The procedure for demonstration that existing network fits to requirements of the TSIs is executed on voluntary bases, so when EI declaration do not exist then the parameter is optional. If EI declaration was not issued, then field shall be left empty. |
|
Data presentation |
Predefined CharacterString: [CC/RRRRRRRRRRRRRR/YYYY/NNNNNN]) |
|
References |
[22] Recommendation 2014/881/EU ‘Document about practical arrangements for transmitting interoperability documents' [23] |
|
Validation |
The validation is described before this Table, in section 2.3. |
|
|
|
|
Number |
1.2.2.0.5.5 |
|
Title |
Length of tunnel |
|
XML Name |
OP Siding Tunnel Parameter ITU_Length |
|
Definition |
Length of a tunnel in metres from entrance portal to exit portal. |
|
Explanations on definition |
Length of a tunnel in metres from portal to portal at the level of the top of rail. |
|
Can be repeated |
N |
|
Applicable |
Y/N/NYA |
|
Y only for a tunnel with length of 100 metres or more. |
|
|
Data presentation |
[NNNNN] |
|
|
|
|
Number |
1.2.2.0.5.6 |
|
Title |
Existence of emergency plan |
|
XML Name |
OP Siding Tunnel Parameter ITU_EmergencyPlan |
|
Definition |
Indication whether emergency plan exists. |
|
Can be repeated |
N |
|
Applicable |
Y/ N/NYA |
|
Explanation on applicability: Y for tunnels longer than 1 km, in accordance with section 4.4.2 of SRT TSI, the emergency plan is mandatory only for tunnel length of more than 1km. ‘N’=not applicable can be selected for short tunnels of less than 1 km, as for them the fire category according SRT TSI does not exist. |
|
|
Data presentation |
Single selection from the predefined list: Y N |
|
General Explanations |
Emergency plan has to be a document developed for each tunnel under the direction of the IM, in co-operation, where appropriate, with RUs, Rescue services and relevant authorities. It shall be consistent with the self-rescue, evacuation and rescue facilities provided. |
|
Reference |
SRT TSI: 4.4.2 |
|
|
|
|
Number |
1.2.2.0.5.7 |
|
Title |
Fire category of rolling stock required |
|
XML Name |
OP Siding Tunnel Parameter ITU_FireCatReq |
|
Definition |
Categorisation on how a passenger train with a fire on board will continue to operate for a defined time period. |
|
Can be repeated |
N |
|
Applicable |
Y/N/NYA |
|
Explanation on applicability: ‘N’=not applicable shall be selected for short tunnels of less than 1 km, as for them the fire category according SRT TSI does not exist. |
|
|
Data presentation |
Single selection from the predefined list: A B none |
|
Explanation on data presentation: Wherever category B is not needed, generally the category A has to be understood as the default value. ‘none’ shall be selected when none of A or B fire category is applied for a specific tunnel. |
|
|
References |
SRT TSI : 1.1.3 CR LOC&PAS TSI: 4.2.10.1 |
|
|
|
|
Number |
1.2.2.0.5.8 |
|
Title |
National fire category of rolling stock required |
|
XML Name |
OP Siding Tunnel Parameter ITU_NatFireCatReq |
|
Definition |
Categorisation on how a passenger train with a fire on board will continue to operate for a defined time period - according to national rules if they exist. |
|
Can be repeated |
N |
|
Applicable |
Y/N/NYA |
|
Explanation on applicability: ‘N’=not applicable shall be selected when respective national rules do not exist Y only for tunnels when for the parameter 1.2.2.0.5.7 the option ‘none’ was selected. |
|
|
Data presentation |
CharacterString |
|
Explanation on data presentation: Data shall include both the category and brief name of the document introducing the categorisation |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Number |
1.2.2.0.6 |
|
Title |
Contact line system |
|
XML Name |
ECS |
|
Can be repeated |
N |
|
|
|
|
|
|
|
Number |
1.2.2.0.6.1 |
|
Title |
Maximum current at standstill per pantograph |
|
XML Name |
ECS_MaxStandstillCurrent |
|
Definition |
Indication of the maximum allowable train current at standstill for DC systems expressed in amperes. |
|
Explanation on Definition |
Parameter related to current taken by the vehicle when it is not in a traction or regenerative mode, e.g. preheating, air-condition, etc. |
|
Applicable |
Y/N/NYA |
|
Explanation on applicability: This parameter is applicable (“Y”) only if “Overhead contact line (OCL)” is selected for parameter 1.1.1.2.2.1.1 and if DC system is selected in 1.1.1.2.2.1.2 It can be not applicable, at the initiative of the IM, in the following cases: |
|
|
Can be repeated |
Y |
|
Data presentation |
[NNN] |
|
References |
ENE TSI: 4.2.5 LOC&PAS TSI: 4.2.8.2.5 |
|
|
|
|
|
|
|
Number |
1.2.3 |
|
Title |
Rules and restrictions |
|
XML Name |
OPRules |
|
Can be repeated |
N |
|
Explanations |
The two following parameters: /RUL_LocalRulesOrRestrictions are declared at the level of operational point |
|
|
|
|
|
|
|
Number |
1.2.3.1 |
|
Title |
Existence of rules and restrictions of a strictly local nature |
|
XML Name |
RUL_LocalRulesOrRestrictions |
|
Definition |
Existence of rules and restrictions of a strictly local nature |
|
Applicable |
Y/N/NYA |
|
Can be repeated |
N |
|
Data presentation |
Single selection from the predefined list: |
If the siding is not electrified in DC
Siding destined to freight traffic, whose trains have a low consumption in stationary (the maximum demand of energy is due to air conditioning systems, which is not significant in these trains).
Siding used in access to depots or workshops.
1.2.3.1 /existence of rules and restrictions of a strictly local nature
1.2.3.2/Documents regarding the rules or restrictions of a strictly local nature available by the IM /RUL_LocalRulesOrRestrictionsDocRef-
|
|
Y/N "In case of Y, the RU have to contact the IM to be informed of these conditions" |
|
General explanations |
There is a general obligation for Member States to notify existing national rules but: “Member States may decide not to notify rules and restrictions of a strictly local nature. In such cases, Member States shall mention those rules and restrictions in the registers of infrastructure.” In this eventuality, this parameter allows the IM accordingly to its Member State decision to declare the existence of such rules and to provide them with the parameter 1.2.3.2 Documents regarding the rules or restrictions of a strictly local nature available by the IM |
|
Reference |
IOD: Notification of national rules Art 14. 11: regarding the rules or restrictions of a strictly local nature available by the IM |
|
Validation |
|
|
|
|
|
|
|
|
|
|
|
Number |
1.2.3.2 |
|
Title |
Documents regarding the rules or restrictions of a strictly local nature available by the IM |
|
XML Name |
RUL_LocalRulesOrRestrictionsDocRef |
|
Definition |
Electronic document available from the IM stored by the Agency providing additional information |
|
Applicable |
Y/N/NYA |
|
Can be repeated |
Y |
|
Data presentation |
CharacterString |
|
General explanations |
The document itself has to be upload by the NRE via the “reference document management” functionality. The reference of the document is provided for the parameter using the characterstring format. |
|
Reference |
IOD: Notification of national rules Art 14. 11. Member States may decide not to notify rules and restrictions of a strictly local nature. In such cases, Member States shall mention those rules and restrictions in the registers of infrastructure referred to in Article 49 |
|
Validation |
|
|
|
|
Lists of Borders points and of Domestic Border points
The list of border points below is still under development. Some questions are still pending as:
How to deal with sections of line that cross the border several times between two following OPs.
Consistency between the geographical coordinates provided by NREs
It has been developed by the Agency on the basis of information and agreement from NREs. Any change shall be justified and agreed by the relevant NREs, sent to ERA for the numbering (if needed) of the border point and published.
Making the railway system work better for society.
Table 6 : List of border points
|
BP NAME |
Between MS |
Between OPs |
Latitude |
Longitude |
||
|
EU00001 |
Germany |
Netherlands |
Ihrhove |
Nieuweschans |
53.187480 |
7.210411 |
|
EU00002 |
Germany |
Netherlands |
Bad Bentheim |
Oldenzaal |
52.309093 |
7.040075 |
|
EU00003 |
Germany |
Netherlands |
Gronau |
Enschede |
52.218058 |
6.979838 |
|
EU00004 |
Germany |
Netherlands |
Emmerich |
Zevenaar Oost |
51.901252 |
6.137680 |
|
EU00005 |
Germany |
Netherlands |
Kaldenkirchen |
Venlo |
51.340989 |
6.192566 |
|
EU00006 |
Germany |
Netherlands |
Herzogenrath |
Landgraaf |
50.880347 |
6.084949 |
|
EU00007 |
Germany |
Belgium |
Aachen West |
Montzen |
50.753375 |
6.021325 |
|
EU00008 |
Germany |
Belgium |
Aachen Hbf/Aachen Süd |
Abzw. Hammerbrücke, Hergenrath |
50.718479 |
6.041337 |
|
EU00009 |
Germany |
Luxembourg |
Igel |
Wasserbillig |
49.7138000 |
6.5066000 |
|
EU00010 |
Germany |
France |
Perl |
Apach |
49.4690000 |
6.3696000 |
|
EU00011 |
Germany |
France |
Hemmersdorf |
Bouzonville |
49.3360000 |
6.5911000 |
|
EU00012 |
Germany |
France |
Saarbrücken |
Forbach |
49.2140000 |
6.9442000 |
|
EU00013 |
Germany |
France |
Hanweiler |
Sarreguemines |
49.1119000 |
7.0573000 |
|
BP NAME |
Between MS |
Between OPs |
Latitude |
Longitude |
||
|
EU00014 |
Germany |
France |
Winden |
Wissembourg |
49.0271000 |
7.9788000 |
|
EU00015 |
Germany |
France |
Wörth |
Lauterbourg |
48.9752000 |
8.1954000 |
|
EU00016 |
Germany |
France |
Kehl |
Strasbourg |
48.5756000 |
7.8010000 |
|
EU00017 |
Germany |
France |
Neuenburg |
Bantzenheim |
47.8143000 |
7.5464000 |
|
EU00018 |
Germany |
Switzerland |
Weil-am-Rhein - RB |
Basel Bad Bhf RB |
47.58535 |
7.60395 |
|
EU00019 |
Germany |
Switzerland |
Grenzach |
Basel Bad Bhf PB |
47.56373 |
7.63597 |
|
EU00020 |
Germany |
Switzerland |
Lörrach |
Riehen |
47.59489 |
7.65703 |
|
EU00021 |
Germany |
Switzerland |
Waldshut (DB) |
Koblenz (AG) |
47.61010 |
8.23502 |
|
EU00022 |
Germany |
Switzerland |
Lotstetten [1] |
Rafz |
47.61997 |
8.56120 |
|
EU00023 |
Germany |
Switzerland |
Neuhausen-am-Rheinfall [2] |
Jestetten |
47.67262 |
8.60292 |
|
EU00024 |
Germany |
Switzerland |
Erzingen (Baden) |
Trasadingen |
47.66189 |
8.43175 |
|
EU00025 |
Germany |
Switzerland |
Thayngen |
Singen |
47.74578 |
8.72803 |
|
EU00026 |
Germany |
Switzerland |
Konstanz |
Kreuzlingen |
47.65460 |
9.17769 |
|
EU00027 |
Germany |
Switzerland |
Konstanz |
Kreuzlingen Hafen |
47.65350 |
9.17890 |
|
EU00028 |
Germany |
Austria |
Lindau-Reutin |
Lochau-Hörbranz |
47.5344 |
9.7360 |
|
EU00029 |
Germany |
Austria |
Pfronten-Steinach |
Vils |
47.5604 |
10.5905 |
|
EU00030 |
Germany |
Austria |
Griesen |
Ehrwald |
47.4697 |
10.9302 |
|
EU00031 |
Germany |
Austria |
Mittenwald |
Scharnitz |
47.3978 |
11.2675 |
|
EU00032 |
Germany |
Austria |
Kiefersfelden |
Kufstein |
47.6012 |
12.1774 |
|
EU00033 |
Germany |
Austria |
Freilassing |
Salzburg |
47.8319 |
12.9890 |
|
BP NAME |
Between MS |
Between OPs |
Latitude |
Longitude |
||
|
EU00034 |
Germany |
Austria |
Simbach |
Braunau |
48.2620 |
13.0384 |
|
EU00035 |
Germany |
Austria |
Passau |
Wernstein |
48.5633 |
13.4517 |
|
EU00036 |
Germany [3] |
Czech Republic |
Bayerisch Eisenstein |
Železná Ruda st.hr. |
49.12162 |
13.20916 |
|
EU00037 |
Germany |
Czech Republic |
Furth im Wald |
Česká Kubice st.hr. |
49.33266 |
12.87956 |
|
EU00038 |
Germany |
Czech Republic |
Schirnding |
Cheb st.hr. |
50.08700 |
12.25349 |
|
EU00039 |
Germany |
Czech Republic |
Bad Brambach [4] |
Vojtanov st.hr. |
50.21365 |
12.32714 |
|
EU00040 |
Germany |
Czech Republic |
Zwotental |
Kraslice st.hr. |
50.35392 |
12.46645 |
|
EU00041 |
Germany |
Czech Republic |
Johanngeorgenstadt |
Potůčky st.hr. |
50.43227 |
12.73535 |
|
EU00042 |
Germany |
Czech Republic |
Cranzahl |
Vejprty st.hr. |
50.50482 |
13.03204 |
|
EU00043 |
Germany |
Czech Republic |
Bad Schandau |
Děčín st.hr. |
50.85942 |
14.22218 |
|
EU00044 |
Germany |
Czech Republic |
Sebnitz |
Dolní Poustevna st.hr. |
50.98116 |
14.27914 |
|
EU00045 |
Germany |
Czech Republic |
Ebersbach (Sachs) |
Rumburk st.hr. |
50.99774 |
14.57976 |
|
EU00046 |
Germany |
Czech Republic |
Großschönau |
Varnsdorf st.n.st.hr. |
50.90259 |
14.64450 |
|
EU00047 |
Germany |
Czech Republic |
Seifhennersdorf |
Varnsdorf st.hr. |
50.92107 |
14.60403 |
|
EU00048 |
Germany |
Poland |
Zittau |
Porajów |
50.89360 |
14.83100 |
|
EU00049 |
Germany |
Poland |
Görlitz |
Zgorzelec |
51.14410 |
14.99260 |
|
EU00050 |
Germany |
Poland |
Horka |
Węgliniec |
51.28740 |
15.03260 |
|
EU00051 |
Germany |
Poland |
Forst (Lausitz) |
Tuplice |
51.73800 |
14.66170 |
|
EU00052 |
Germany |
Poland |
Guben |
Gubin |
51.97410 |
14.70740 |
|
EU00053 |
Germany |
Poland |
Frankfurt (Oder) |
Rzepin |
52.32260 |
14.57860 |
|
BP NAME |
Between MS |
Between OPs |
Latitude |
Longitude |
||
|
EU00054 |
Germany |
Poland |
Küstrin-Kietz |
Kostrzyn |
52.58240 |
14.63060 |
|
EU00055 |
Germany |
Poland |
Tantow |
Szczecin Gumieńce |
53.32720 |
14.41650 |
|
EU00056 |
Germany |
Poland |
Löcknitz |
Szczecin Gumieńce |
53.41740 |
14.37530 |
|
EU00057 |
Germany |
Poland |
Hirschfelde |
Hirschfelde Grenze |
50.94970 |
14.89570 |
|
EU00058 |
Germany |
Poland |
Hagenwerder |
Krzewina Zgorzelecka |
51.04800 |
14.95790 |
|
EU00059 |
Denmark |
Germany |
Padborg |
Abzw. Flensburg Friedensweg |
54,815211 |
9,362975 |
|
EU00059 |
Germany |
Denmark |
Abzw. Flensburg Friedensweg |
Padborg |
54.81690 |
9.36413 |
|
EU00060 |
Austria |
Czech Republic |
Summerau |
Horní Dvořiště st.hr. |
48.5930684 |
14.4337144 |
|
EU00061 |
Austria |
Czech Republic |
Gmünd N.Ö. |
České Velenice st.hr. |
48.7644450 |
14.9683315 |
|
EU00062 |
Austria |
Czech Republic |
Retz |
Znojmo st.hr. |
48.7736541 |
16.0146800 |
|
EU00063 |
Austria |
Czech Republic |
Bernhardsthal |
Břeclav st.hr. |
48.7125441 |
16.8683839, |
|
EU00064 |
Czech Republic |
Poland |
Frýdlant v Č.st.hr. |
Zawidów |
51,0122497 |
15,0379603 |
|
EU00065 |
Czech Republic |
Poland |
Harrachov st.hr. |
Szklarska Poręba Górna |
50,7783593 |
15,3963301 |
|
EU00066 |
Czech Republic |
Poland |
Královec st.hr. |
Kamienna Góra |
50,6862142 |
15,9847073 |
|
EU00067 |
Czech Republic |
Poland |
Meziměstí st.hr. |
Mieroszów |
50,6363285 |
16,2203686 |
|
EU00068 |
Poland |
Otovice st.hr. |
Ścinawka Średnia |
50.55084 |
16.41019 |
|
|
BP NAME |
Between MS |
Between OPs |
Latitude |
Longitude |
||
|
|
Czech Republic |
|
|
|||
|
EU00069 |
Czech Republic |
Poland |
Lichkov st.hr. |
Międzylesie |
50,0985290 |
16,6910866 |
|
EU00070 |
Czech Republic |
Poland |
Mikulovice st.hr. |
Głuchołazy |
50,3073883 |
17,3533552 |
|
EU00071 |
Czech Republic |
Poland |
Jindřichov ve Slezsku st.hr. |
Głuchołazy |
50,2747098 |
17,5047550 |
|
EU00072 |
Czech Republic |
Poland |
Bohumín-Vrbice st.hr. |
Chałupki |
49,9163930 |
18,3224690 |
|
EU00073 |
Czech Republic |
Poland |
Bohumín st.hr. |
Chałupki |
49,9164400 |
18,3225230 |
|
EU00074 |
Czech Republic |
Poland |
Petrovice u Karviné.st.hr. |
Zebrzydowice |
49,8844722 |
18,5701565 |
|
EU00075 |
Czech Republic |
Poland |
Český Těšín st. hr. |
Cieszyn |
49,7521247 |
18,6187543 |
|
EU00076 |
Czech Republic |
Slovakia |
Horní Lideč st.hr. |
Lúky pod Makytou št. hr. |
49.17981 |
18.12982 |
|
EU00077 |
Czech Republic |
Slovakia |
Vlársky průsmyk st.hr. |
Horné Srnie št. hr. |
49.03166 |
18.05331 |
|
EU00078 |
Czech Republic |
Slovakia |
Velká nad Veličkou st.hr. |
Vrbovce št. hr. |
48.82603 |
17.51682 |
|
BP NAME |
Between MS |
Between OPs |
Latitude |
Longitude |
||
|
EU00079 |
Czech Republic |
Slovakia |
Sudoměřice nad Moravou st.hr. |
Skalica na Slovensku št. hr. |
48.86982 |
17.24065 |
|
EU00080 |
Czech Republic |
Slovakia |
Hodonín st.hr. |
Holíč nad Moravou št. hr. |
48.83772 |
17.12643 |
|
EU00081 |
Czech Republic |
Slovakia |
Lanžhot st.hr. |
Kúty št. hr. |
48.71112 |
17.00042 |
|
EU00082 |
Czech Republic |
Slovakia |
Mosty u Jablunkova st.hr. |
Čadca št. hr. |
49.49439 |
18.76439 |
|
EU00083 |
Belgium |
France |
Esplechin |
Wannehain |
3.2784511 |
50.5720246 |
|
EU00084 |
Belgium |
France |
Mouscron |
Tourcoing |
3.1961674 |
50.7220695 |
|
EU00085 |
Belgium |
France |
Blandain |
Baisieux |
3.2636772 |
50.6174356 |
|
EU00086 |
Belgium |
France |
Quévy |
Aulnoye |
3.9083749 |
50.3288424 |
|
EU00087 |
Belgium |
France |
Erquelines |
Jeumont |
4.1091807 |
50.3027051 |
|
EU00088 |
Belgium |
France |
Aubange |
Longwy |
5.8128487 |
49.5474178 |
|
EU00089 |
Belgium |
Netherlands |
Antwerpen-Noorderkempen |
Breda (grens) |
51.485665 |
4.734452 |
|
EU00090 |
Belgium |
Netherlands |
Essen |
Roosendaal |
51.469130 |
4.448921 |
|
EU00091 |
Belgium |
Netherlands |
Neerpelt |
Budel |
51.247263 |
5.555298 |
|
EU00092 |
Belgium |
Netherlands |
Lanaken |
Maastricht |
50.880098 |
5.666877 |
|
EU00093 |
Belgium |
Netherlands |
Visé |
Eijsden / Maastricht Randwyck |
50.758825 |
5.703065 |
|
EU00094 |
Belgium |
Netherlands |
Zelzate |
Sas van Gent |
51.210866 |
3.799830 |
|
EU00095 |
Belgium |
Luxemburg |
Gouvy |
Troisvierges |
50,1730 |
5,9653 |
|
BP NAME |
Between MS |
Between OPs |
Latitude |
Longitude |
||
|
EU00096 |
Belgium |
Luxemburg |
Autelbas |
Kleinbettingen |
49,6437 |
5,9042 |
|
EU00097 |
Belgium |
Luxembourg |
Aubange |
Pétange |
49,5518 |
5,8250 |
|
EU00098 |
Belgium |
Luxemburg |
Athus |
Pétange |
49,5518 |
5,8106 |
|
EU00099 |
France |
Luxembourg |
Mont-St-Martin |
Pétange |
49,5433 |
5,8106 |
|
EU00100 |
France |
Luxembourg |
Audun-le Tiche |
Esch-sur-Alzette |
49,4859 |
5,9688 |
|
EU00101 |
France |
Luxembourg |
Volmerange-les-Mines |
Dudelange-Usines |
|
|
|
EU00102 |
France |
Luxembourg |
Thionville |
Bettembourg |
49,4720532 |
6,1078419 |
|
EU00103 |
Austria |
Hungary |
Baumgarten |
Sopron |
47.7136868847223 |
16.5413599522395 |
|
EU00104 |
Austria |
Hungary |
Loipersbach-Schattendorf |
Sopron |
47.6989654931559 |
16.4940757080922 |
|
EU00105 |
Austria |
Hungary |
Nickelsdorf |
Hegyeshalom |
47.9384856496069 |
17.0954082578180 |
|
EU00106 |
Austria |
Hungary |
Pamhagen |
Fertöszéplak-Fertöd |
47.6882186710393 |
16.8839494446881 |
|
EU00107 |
Austria |
Hungary |
Deutschkreutz |
Harka |
47.6267713611272 |
16.6248597012975 |
|
EU00108 |
Austria |
Hungary |
Jennersdorf |
Szentgotthárd |
46.9504875132700 |
16.2461343496966 |
|
EU00109 |
Austria |
Slovakia |
Kittsee |
Bratislava-Petržalka št. hr. |
48.102834 |
17.084221 |
|
EU00110 |
Austria |
Slovakia |
Marchegg |
Devínska Nová Ves št. hr. |
48.241229 |
16.946641 |
|
EU00111 |
Austria |
Slovenia |
Bleiburg |
Prevalje |
46.5667 |
14.8399 |
|
EU00112 |
Austria |
Slovenia |
Rosenbach |
Jesenice |
46.4815 |
14.0199 |
|
EU00113 |
Austria |
Slovenia |
Spielfeld-Straß |
Šentilj |
46.6920 |
15.6404 |
|
EU00114 |
Austria |
Italy |
Sillian |
Prato alla Drava |
46,74025 |
12,37123 |
|
EU00115 |
Austria |
Italy |
Steinach in Tirol |
Brennero |
47.0067 |
11.5074 |
|
BP NAME |
Between MS |
Between OPs |
Latitude |
Longitude |
||
|
EU00116 |
Austria |
Italy |
Thörl-Maglern |
Tarvisio Boscoverde |
46,53482 |
13,64054 |
|
EU00117 |
Austria |
Lichtenstein |
Tosters |
Nendeln |
47.2188547 |
9.5697512 |
|
EU00118 |
Austria |
Switzerland |
Lustenau |
St. Margrethen |
47.447697 |
9.657876 |
|
EU00119 |
France |
Spain |
Hendaya |
Irún/Irún Cambiador |
43.35065 |
-1.78589 |
|
EU00120 |
France |
Spain |
Cerbère |
PortBou/Portbou Cambiador |
42.43494 |
3.15970 |
|
EU00121 |
France |
Spain |
RFF - TP FERRO |
Límite Adif-TPFerro |
42.45679 |
2.86245 |
|
EU00122 |
France |
Spain |
La Tour de Carol-Envigt |
Puigcerdà |
42.44716 |
1.91449 |
|
EU00123 |
Portugal |
Spain |
Valença do Minho |
Tui |
42,03630 |
-8,64676 |
|
EU00124 |
Portugal |
Spain |
Vilar Formoso |
Fuente de Oñoro |
40,60570 |
-6,82600 |
|
EU00125 |
Portugal |
Spain |
Elvas |
Badajoz |
38,92024 |
-7,03015 |
|
EU00126 |
France |
Italy |
Menton-Garavan |
Ventimiglia / Ventimiglia Parco Roja |
43,78537 |
7,52957 |
|
EU00127 |
France |
Italy |
Modane |
Bardonecchia |
45,13757 |
6,68342 |
|
EU00128 |
France |
Italy |
Vievola |
Limone Piemonte |
44,15268 |
7,56981 |
|
EU00129 |
France |
Italy |
Breil-sur-Roja |
Olivetta - S. Michele |
43,89028 |
7,53092 |
|
EU00130 |
France |
Switzerland |
Pougny-Chancy |
La Plaine |
46,177452 |
5,990589 |
|
EU00131 |
France |
Switzerland |
Annemasse |
Chènes-Bourg |
46,193923 |
6,212824 |
|
EU00132 |
France |
Switzerland |
Les Longevilles-Rochejean |
Vallorbe |
46,713594 |
6,347762 |
|
EU00133 |
France |
Switzerland |
Pontarlier |
Les Verrières |
46,89917 |
6,45899 |
|
EU00134 |
France |
Switzerland |
Morteau |
Le Locle-Col-des-Roches |
47,050231 |
6,716949 |
|
EU00135 |
France |
Switzerland |
Delle |
Boncourt |
47,502777 |
7,012894 |
|
BP NAME |
Between MS |
Between OPs |
Latitude |
Longitude |
||
|
EU00136 |
France |
Switzerland |
Leymen |
Flüh |
|
|
|
EU00137 |
Switzerland |
France |
Rodersdorf [7] |
Leymen |
|
|
|
EU00138 |
France |
Switzerland |
Saint-Louis |
Basel St. Johann |
47,577565 |
7,567592 |
|
EU00139 |
France |
Switzerland |
St.Gingolph France |
St.Gingolph |
46,393185 |
6,804059 |
|
EU00140 |
Switzerland |
France |
Le Châtelard-Frontière [8] |
Vallorcine |
46,051295 |
6,947907 |
|
EU00141 |
Denmark |
Sweden |
Peberholm |
Lernacken |
55,605923 |
12,738071 |
|
EU00142 |
Lithuania |
Poland |
Mockava |
Trakiszki |
54,26487 |
23,22999 |
|
EU00143 |
Latvia |
Russia |
Zilupe |
Sebeža |
56,38863 |
28,17265 |
|
EU00144 |
Latvia |
Russia |
Kārsava |
Pitalova |
56,85329 |
27,72848 |
|
EU00145 |
Latvia |
Lithuania |
Meitene |
Joniškis |
56,36361 |
23,65876 |
|
EU00146 |
Latvia |
Lithuania |
Eglaine |
Rokiškis |
55,94445 |
26,04576 |
|
EU00147 |
Latvia |
Lithuania |
Kurcums |
Turmantas |
55,70351 |
26,46777 |
|
EU00148 |
Latvia |
Lithuania |
Reņģe |
Mažeikiai |
56,37945 |
22,62039 |
|
EU00149 |
Italy |
Slovenia |
Gorizia C.le |
Vrtojba |
45,92315 |
13,62690 |
|
EU00150 |
Italy |
Slovenia |
Villa Opicina |
Stanjel |
45,72324 |
13,81084 |
|
EU00151 |
Italy |
Slovenia |
Villa Opicina |
Sezana |
45,68757 |
13,83348 |
|
EU00152 |
Italy |
Switzerland |
Pino Tronzano |
Ranzo S. Abbondio |
46,10370 |
8,756673 |
|
EU00153 |
Italy |
Switzerland |
Iselle |
Brig |
46,27094 |
8,09526 |
|
EU00154 |
Italy |
Switzerland |
Como St. Giovanni |
Chiasso |
45,83074 |
9,03423 |
|
EU00155 |
Italy |
Switzerland |
Cucciago (via Bivio Rosales) |
Chiasso |
45,83074 |
9,03423 |
|
BP NAME |
Between MS |
Between OPs |
Latitude |
Longitude |
||
|
EU00156 |
Italy |
Switzerland |
Gaggiolo [9] |
Stabio |
|
|
|
EU00157 |
Switzerland |
Liechtenstein - Austria |
Buchs SG |
Schaan-Vaduz |
47.16453 |
9.49064 |
|
EU00158 |
Poland |
Slovakia |
Zwardoń |
Skalité št. hr. |
49.50388 |
18.97193 |
|
EU00159 |
Poland |
Slovakia |
Muszyna |
Plaveč št. hr. |
49.29605 |
20.92397 |
|
EU00160 |
Poland |
Slovakia |
Łupków |
Medzilaborce št. hr. |
49.25086 |
22.03846 |
|
EU00161 |
Slovakia |
Ukraine |
Maťovce ŠRT št. hr. |
Uzhhorod |
48.56241 |
22.16063 |
|
EU00162 |
Slovakia |
Ukraine |
Čierna nad Tisou št. hr. |
Chop |
48.43276 |
22.13762 |
|
EU00163 |
Slovakia |
Ukraine |
Čierna nad Tisou ŠRT št. hr. |
Chop |
48.43276 |
22.13762 |
|
EU00164 |
Hungary |
Slovakia |
Sátoraljaújhely |
Slovenské Nové Mesto št. hr. |
48,38981 |
21,66948 |
|
EU00165 |
Hungary |
Slovakia |
Hidasnémeti |
Čaňa št. hr. |
48,52877 |
21,26256 |
|
EU00166 |
Hungary |
Slovakia |
Bánréve |
Lenartovce št. hr. |
48,30180 |
20,33859 |
|
EU00167 |
Hungary |
Slovakia |
Somoskőújfalu |
Fiľakovo št. hr. |
48,16836 |
19,82116 |
|
EU00168 |
Hungary |
Slovakia |
Nógrádszakál |
Malé Straciny št. hr. |
48,16365 |
19,51302 |
|
EU00169 |
Hungary |
Slovakia |
Ipolytarnóc |
Lučenec št. hr. |
48,24626 |
19,63834 |
|
EU00170 |
Hungary |
Slovakia |
Szob |
Štúrovo št. hr. |
47,82362 |
18,85269 |
|
EU00171 |
Hungary |
Slovakia |
Komárom |
Komárno št. hr. |
47,75657 |
18,08790 |
|
EU00172 |
Hungary |
Slovakia |
Rajka |
Rusovce št. hr. |
48,01373 |
17,17945 |
|
EU00173 |
Poland |
Ukraine |
Medyka |
Mościska |
49,8051 |
22,9615 |
|
EU00174 |
Poland |
Ukraine |
Werchrata |
Rawa Ruska |
50,2408 |
23,5254 |
|
BP NAME |
Between MS |
Between OPs |
Latitude |
Longitude |
||
|
EU00175 |
Poland |
Ukraine |
Hrebenne |
Rawa Ruska |
50,2949 |
23,6076 |
|
EU00176 |
Poland |
Ukraine |
Hrubieszów Miasto |
Izov |
|
|
|
EU00177 |
Poland |
Ukraine |
Hrubieszów LHS |
Izov |
|
|
|
EU00178 |
Poland |
Ukraine |
Dorohusk |
Jahodyn |
51,1799 |
23,8127 |
|
EU00179 |
Poland |
Belarus |
Terespol |
Brześć |
52,0912 |
23,6221 |
|
EU00180 |
Poland |
Belarus |
Czeremcha |
Wysokie |
52,4645 |
23,3523 |
|
EU00181 |
Poland |
Belarus |
Siemianówka |
Świsłocz |
52,939 |
23,9166 |
|
EU00182 |
Poland |
Belarus |
Kuźnica Białostocka |
Grodno |
53,5444 |
23,6516 |
|
EU00183 |
Poland |
Russia |
Skandawa |
Železnodorožnyj |
54,3335 |
21,3032 |
|
EU00184 |
Poland |
Russia |
Braniewo |
Mamonowo |
54,4366 |
19,8735 |
|
EU00185 |
Hungary |
Slovenia |
Őriszentpéter |
Hodoš |
46,81974 |
16,34172 |
|
EU00186 |
Greece |
Turkey |
Pythion |
UzunKopru |
41.36209 |
26.63149 |
|
EU00187 |
Bulgaria |
Greece |
Svilengrad |
Dikea |
41.74770 |
26.16666 |
|
EU00188 |
Bulgaria |
Greece |
Kulata |
Promachon |
41.37950 |
23.36433 |
|
EU00189 |
Greece |
FYROM |
Idomeni |
Gevgelija |
41.12826 |
22.51719 |
|
EU00190 |
Greece |
FYROM |
Neos Kafkasos |
Kremenitsa |
40.90731 |
21.46449 |
|
EU00191 |
Czech Republic |
Poland |
Hrádek nad Nisou st.hr. |
Porajów |
50.86917 |
14.83999 |
|
EU00192 |
Hungary |
Ukraine |
Eperjeske |
Соловка |
48,37405 |
22,25738 |
|
EU00193 |
Hungary |
Ukraine |
Záhony |
Чоп |
48,41547 |
22,18605 |
|
BP NAME |
Between MS |
Between OPs |
Latitude |
Longitude |
||
|
EU00194 |
Hungary |
Romania |
Biharkeresztes |
Oradea |
47,124529 |
21,792944 |
|
EU00195 |
Hungary |
Romania |
Kötegyán |
Salonta |
46,760782 |
21,487366 |
|
EU00196 |
Hungary |
Romania |
Lőkösháza |
Curtici |
46,409703 |
21,252697 |
|
EU00197 |
Hungary |
Romania |
Nyírábrány |
Valea lui Mihai |
47,525013 |
22,031618 |
|
EU00198 |
Hungary |
Romania |
Ágerdőmajor |
Berveni |
47,769806 |
22,435682 |
|
EU00199 |
Hungary |
Serbia |
Kelebia |
Суботица / Subotica |
46,16952 |
19,63273 |
|
EU00200 |
Hungary |
Serbia |
Röszke |
Хоргош / Horgoš |
46,23042 |
20,00099 |
|
EU00201 |
Croatia |
Hungary |
Botovo |
Gyékényes |
46,24703 |
16,94493 |
|
EU00202 |
Croatia |
Hungary |
Beli Manastir |
Magyarboly |
45,79834 |
18,55795 |
|
EU00203 |
Croatia |
Hungary |
Kotoriba |
Murakeresztur |
46,35918 |
16,85202 |
|
EU00204 |
Latvia |
Belarus |
Indra |
Polocka |
55,84455 |
27,63814 |
|
EU00205 |
Latvia |
Estonia |
Lugaži |
Valga |
57,768847 |
26,023853 |
|
EU00206 |
Bulgaria |
Romania |
Ruse razpredelitelna |
Giurgiu Nord |
43,887193 |
26,007716 |
|
EU00207 |
Bulgaria |
Romania |
Ruse |
Giurgiu Nord |
43,887193 |
26,007716 |
|
EU00208 |
Bulgaria |
Romania |
Vidin tovarna |
Golenti |
44,003012 |
22,948364 |
|
EU00209 |
Bulgaria |
Romania |
Vidin patnicheska |
Golenti |
44,003012 |
22,948364 |
|
EU00210 |
Bulgaria |
Romania |
Kardam |
Negru Voda |
43,785906 |
28,151004 |
|
EU00211 |
Bulgaria |
Serbia |
Kalotina Zapad |
Dimitrovgrad |
42,99824 |
22,83536 |
|
EU00212 |
Bulgaria |
Turkey |
Svilengrad |
Kapikule |
41,72183 |
26,34738 |
|
EU00213 |
Croatia |
Slovenia |
Mursko Središće |
Lendava |
46,51546 |
16,44405 |
|
BP NAME |
Between MS |
Between OPs |
Latitude |
Longitude |
||
|
EU00214 |
Croatia |
Slovenia |
Kumrovec |
Imeno |
46,11559 |
15,60657 |
|
EU00215 |
Croatia |
Slovenia |
Kamanje |
Metlika |
45,64556 |
15,34289 |
|
EU00216 |
Croatia |
Slovenia |
Savski Marof |
Dobova |
45,89068 |
15,68015 |
|
EU00217 |
Croatia |
Slovenia |
Šapjane |
Ilirska Bistrica |
45,50518 |
14,24422 |
|
EU00218 |
Croatia |
Slovenia |
Čakovec |
Središće ob Dravi |
46,38822 |
16,30414 |
|
EU00219 |
Croatia |
Slovenia |
Buzet |
Podgorje |
45,45398 |
13,95010 |
|
EU00220 |
Croatia |
Slovenia |
Đurmanec |
Rogatec |
46,21231 |
15,77691 |
|
EU00221 |
Croatia |
Bosnia and Herzegovina |
Slavonski Šamac |
Bosanski Šamac |
45,06100 |
18,49626 |
|
EU00222 |
Croatia |
Bosnia and Herzegovina |
Metković |
Čapljina |
43,05886 |
17,65746 |
|
EU00223 |
Croatia |
Bosnia and Herzegovina |
Volinja |
Dobrljin |
45,18939 |
16,48235 |
|
EU00224 |
Croatia |
Bosnia and Herzegovina |
Ličko Dugo Polje razdjelna točka |
Martin Brod |
44,45715 |
16,13599 |
|
EU00225 |
Croatia |
Bosnia and Herzegovina |
Drenovci |
Brčko |
44,86828 |
18,83090 |
|
EU00226 |
Croatia |
Serbia |
Tovarnik |
Šid |
45,14734 |
19,16442 |
|
EU00227 |
Croatia |
Serbia |
Erdut |
Bogojevo |
45,52332 |
19,08632 |
|
EU00228 |
United Kingdom |
France |
Folkestone |
Calais Frethun |
51.01718 |
01.50182 |
|
BP NAME |
Between MS |
Between OPs |
Latitude |
Longitude |
||
|
EU00229 |
United Kingdom |
Ireland |
Newry |
Dundalk |
54,0690 |
-06,3787 |
|
EU00230 |
Germany |
Czech Republic |
Selb-Plossberg |
As |
50.212494 |
12.173480 |
|
EU00231 |
Estonia |
Russia |
Narva |
Ivangorod |
59.367069 |
28.205963 |
|
EU00232 |
Estonia |
Russia |
Koidula |
Petšorõ |
57.837036 |
27.607675 |
|
EU00233 |
Latvia |
Estonia |
Valka |
Valga |
57.769117 |
26.023542 |
|
EU00234 |
Norway |
Sweden |
Kornsjø stasjon |
Mon |
58.93476 |
11.66987 |
|
EU00235 |
Norway |
Sweden |
Magnor stasjon |
Charlottenberg |
59.93187 |
12.24341 |
|
EU00236 |
Norway |
Sweden |
Kopperå stasjon |
Storlien |
63.33700 |
12.06050 |
|
EU00237 |
Norway |
Sweden |
Bjørnfjell stasjon |
Vassijaure |
68.43004 |
18.10572 |
|
EU00238 |
Switzerland |
France |
Chènes-Bougeries |
Annemasse |
46,19604 |
6,23041 |
|
EU00239 |
Sweden |
Finland |
Haparanda |
Tornio |
65,827855 |
24,150731 |
|
EU00240 |
Romania |
Ukraine |
Halmeu |
Diacovo |
47.995400 |
23.002900 |
|
EU00241 |
Romania |
Ukraine |
Campulung pe Tisa |
Teresva |
48.001100 |
23.735200 |
|
EU00242 |
Romania |
Ukraine |
Valea Viseului |
Rahov |
47.920300 |
24.168300 |
|
EU00243 |
Romania |
Ukraine |
Vicsani |
Vadu Siret |
47.976900 |
25.963900 |
|
EU00244 |
Romania |
Moldova |
Ungheni Prut |
Ungheni |
47.199800 |
27.786900 |
|
EU00245 |
Romania |
Moldova |
Falciu |
Prut |
46.259900 |
28.127800 |
|
EU00246 |
Romania |
Moldova |
Galati Larga |
Giurgiulesti |
45.471000 |
28.197600 |
|
BP NAME |
Between MS |
Between OPs |
Latitude |
Longitude |
||
|
EU00247 |
Romania |
Serbia |
Jimbolia |
Kikinda |
45.752200 |
20.701100 |
|
EU00248 |
Romania |
Serbia |
Stamora Moravita |
Vrsac |
45.232500 |
21.271400 |
|
EU00249 |
Germany |
Switzerland |
Weil-am-Rhein – PB |
Basel Bad Bhf PB |
47.58396 |
7.60470 |
Line of SBB on German territory
Line of SBB on German territory
Coordinates are being reviewed due to differences detected
The section of line crosses the border several times although there is no station
Reopening expected for 2017 (CEVA)
, [7], [8] Track gauge 1000 millimetres
[9] Line under construction
The list of Domestic Border points is not yet developed. On the request of NREs, it was agreed that they will manage the domestic border points at national level in a first step. When these lists of national domestic border points will be enough stabilized, and before January 2021, they will be published in the table below.
Table 7: List of domestic border points
|
Domestic BP NAME |
Between IMS |
Between OPs |
Latitude |
Longitude |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
waiting proposals from stake holders
Making the railway system work better for society.
|
Table 8: list of amendment to the previous version Version 1.2.1 - 19/01/2017 |
||
|
Paragraph/Parameter/Table |
Description |
according |
|
all |
Update |
New format of the ERA documents |
|
all |
Cleaning of all the parts of the text let highlighted, strikeout in the previous version a good understanding of the modifications, |
|
|
P 19 : Border point |
Deletion of “or IMs” in the definition |
|
|
P 19 : Domestic border point |
The definition is: located exactly in the point where networks of different IMs are connected in a Member State |
|
|
Parameter 1.1.1.3.7.11 / SOL Track Parameter / CTD_MinAxleLoad |
Modification of the format: [NN.N] No impact on the current work of NREs |
Request of LV NRE |
|
Parameter 1.2.0.0.0.4 / Type of Operational Point |
Type 9: Deletion of “or IMs” in the definition |
|
|
Parameter 1.1.1.3.3.1 / GSM-R version / SOL Track Parameter CRG_Version |
Deletion of the last sentence of the comment |
|
|
Parameter 1.1.1.3.2.2 / ETCS baseline / SOL Track Parameter CPE_Baseline |
Deletion of the last sentence of the comment |
|
|
Parameter 1.1.1.3.5.2 / Need for more than one train protection, control and warning system required on-board / SOL Track Parameter CPO_MultipleRequired |
Deletion of the link with ETCS level (applicability ) |
|
|
Parameter 1.2.0.0.0.2 / Unique OP ID / UniqueOPID |
Deletion of the last line of the Explanations |
|
|
Table 6 |
Update of the definition of some Borders points |
|
|
Table 7 |
Deletion of the previous list of amendments New list |
|
|
Version 1.2 - 07/04/2016: list of modifications to version 1.1 |
||
|
Paragraph/Parameter/Table |
Description |
according |
|
Table 1 and Table 5 |
The modifications highlighted (underlined) in blue in the previous version of the guide are now included. The modifications previously highlighted in green are also cleaned up. Some modifications were introduced by the end of April 2016 in the CUI (test) and will be introduced in the CUI in production by mid May 2016. They are highlighted in grey. The way to use the parameter is advised for the meantime. |
|
|
2.3.6 “the Location point” |
paragraph completed at its end |
Change request 50 (CR50) |
|
2.6 Relations between parameters |
explanation of the use of the “Set” attribute improved |
|
|
Parameters 1.1.0.0.0.3/ SOLOPStart and 1.1.0.0.0.4/ SOLOPEnd |
Reference to parameter 1.2.0.0.0.2 for the definition of “uniqueOPID” |
|
|
Parameters 1.1.0.0.0.3 and 1.1.0.0.0.4 |
SOLOPStart and SOLOPEnd – change format to [AA+AAAAAAAAAA] which is the new format of parameter 1.2.0.0.0.2. |
Consequence of CR 38 |
|
Parameter 1.1.1.1.2.2 / IPP_LineCat |
The parameter will be N (Not applicable) when tables 2 or 3 of 4.2.1(7) of INF TSI are not usable on the UK network for Great Britain according the specific case 7.7.17.1(2). |
CR 72 |
|
Parameter 1.1.1.1.2.5 |
IPP_MaxSpeed – change range of values from [10, 500] to [0, 500] |
CR 34 |
|
Parameter 1.1.1.1.3.3/ ILL_NatGauge |
The previous footnote was deleted. The description of the upper and lower parts of the gauge will be by introducing new parameters |
|
|
Parameter 1.1.1.1.3.6 / ILL_GradProfile |
ILL_GradProfile – change format to [±NN.N] ([±NNNN.NNN], as a consequence of the modification of the format of Parameter 1.2.0.0.0.6 . |
CR 63 |
|
Parameter 1.1.1.1.7.3 |
SOL Track Parameter IHS_AccelerationLevelCrossing : Modification of the definition, update of the explanations on data presentation, statement to have a contact with the IM |
CR 46 |
|
Parameter 1.1.1.1.8.3 |
SOLTunnelStart – change format to [Latitude (NN.NNNN) + Longitude(±NN.NNNN) + km(±NNNN.NNN)] , as a consequence of the modification of the format of Parameter 1.2.0.0.0.6 . |
CR 64 |
|
Parameter 1.1.1.1.8.4 |
SOLTunnelEnd – change format to [Latitude (NN.NNNN) + Longitude(±NN.NNNN) + km(±NNNN.NNN)] , as a consequence of the modification of the format of Parameter 1.2.0.0.0.6 . |
CR 65 |
|
Parameter 1.1.1.2.3.1 / EPA_TSIHeads |
Modification of the list of “Accepted TSI compliant pantograph heads”. This modification will be introduced in the CUI as soon as possible. |
|
|
Parameter 1.1.1.3.2.1 / CPE_Level |
Update of the explanation due to the modification of the applicability condition of Parameter 1.1.1.3.5.1. This modification will be introduced in the CUI as soon as possible. |
|
|
Parameter 1.1.1.3.5.1 / CPO_Installed |
Modification of the applicability condition This modification (highlighted in grey) was introduced by the end of April 2016 in the CUI (test) and will be introduced in the CUI in production by mid May 2016. Update of the explanation |
1.1.1.2.3.1 Accepted TSI compliant pantograph heads |
|
Parameter 1.1.1.3.6.1 / CRS_Installed |
Modification of the applicability condition This modification (highlighted in grey) was introduced by the end of April 2016 in the CUI (test) and will be introduced in the CUI in production by mid May 2016. |
F |
|
Parameter 1.1.1.3.8.1 / CTS_SwitchProtectControlWarn |
Update of the explanation on the applicability |
|
|
Parameter 1.1.1.3.8.2 / CTS_SwitchRadioSystem |
Update of the applicability condition ( wrong reference to parameter 1.1.1.3.7.1) |
|
|
Parameter 1.2.0.0.0.2 |
UniqueOPID – change format to [AA+AAAAAAAAAA] where the first AA is the country code and AAAAAAAAAA is the up to 10 alpha-numeric characters OP code |
CR 38 |
|
Parameter 1.2.0.0.0.4 / OPType |
new type of Operational Point: the domestic border point This modification(highlighted in grey) was decided by the end of April 2016 (test) and will be introduced in the CUI in test and in production as soon as possible |
|
|
Parameter 1.2.0.0.0.6 / OPRailwayLocation |
OPRailwayLocati–n - change of format to [±NNNN.NNN] |
CR 33 |
|
Parameter 1.2.0.0.0.6 / OPRailwayLocation |
Explanation updated to describe the ability to be repeated |
CR 76 |
|
Parameter 1.2.1.0.2.2 / IPP_LineCat |
The parameter will be N (Not applicable) when tables 2 or 3 of 4.2.1(7) of INF TSI are not usable on the UK network for Great Britain according the specific case 7.7.17.1(2). |
CR 72 |
|
Parameter 1.2.1.0.3.3 / ILL_NatGauge |
The previous footnote was deleted. The description of the upper and lower parts of the gauge will be by introducing new parameters |
|
|
Parameter 1.2.1.0.6.7 / IPL_AreaBoardingAid |
Explanation was updated on the mandatory status of the parameter |
|
|
Parameter 1.2.2.0.3.1 / ILL_Gradient |
ILL_Gradient – change format to [NN.N] |
CR 61 |
|
Table 6 |
EU00228 and EU00229 were added |
|
|
Version 1.3 - ??/09/2016: list of modifications to version 1.2 |
||
|
1.1.1.1.3.4 Standard combined transport profile number for swap bodies 1.1.1.1.3.5 Standard combined transport profile number for semi-trailers |
NRE SW: Request to add C/P 371 and 422 RFI: request to add C/P 25, 30 and 384 |
|
|
1.1.1.2.2.4 Permission for regenerative braking |
NSA SE wants to add the option “allowed under conditions” (or with similar signification) for the value of parameter 1.1.1.2.2.4. |
|
|
1.1.1.1.3.1, 1.1.1.1.3.2 and 1.1.1.1.3.3 for SOL and 1.2.1.0.3.1,1.2.1.0.3.2 and 1.2.1.0.3.3 for OP |
Removal of the dependencies to allow to select combinations between interoperability gauge, multinational gauge and national gauges. |
|
|
1.1.1.3.3.1 CRG_Version GSM-R version. |
Need to include Baseline 1 as a value |
|
|
|
|
|
|
Table border points |
Could you please insert it in the Table 6: List of border points in AG. EU00115 Austria Italy Steinach in Tirol Brennero 47.0067 11.5074 EU00117 between Austria and Lichtenstein. Tosters Nendeln 47.21875 9.56960 Mail France/Luxemburg 11/07/2017 EU00099 Mont-St-Martin et Pétange Latitude 49,5433 ; Longitude 5,8106 EU00100 Audun-le-Tiche et Esch-sur-Alzette Latitude 49,4859 ; Longitude 5,9688 EU00102 Thionville et Bettembourg Latitude 49,4721; Longitude 6,1079 |
|
|
|
EU100101 to be deleted |
|
|
NRE AT How to represent a fixed intsallation linked to a running track in an OP |
As already said in last RINF meeting in March, I would like to discuss with you the following issue in order to find a best/common solution for such a case in RINF: Few of Austrian OPs have some of their fixed installations for servicing trains (for example the water restocking) not on the siding but on running track. The Application Guide does not specify such a case. But we have it and some of Austrian railway undertakings consider important to map this services in RINF, because of future application of RINF and its public accessibility. In order to put this fixed installations for servicing trains in RINF, we elaborate two scenarios. In both scenarios we get the valid RINF XML-file with correct syntax, but they don’t reflect reality. Scenario 1: We map such running track (with the fixed installations for servicing trains) as running track as well as siding in its RINF operational point. Disadvantage: the siding is virtual one Scenario 2: The operational point, let call it “Vienna real”, is divided in to two OPs: (real) OP “Vienna” and (virtual) OP “Vienna train technical services” of OPType Train technical services. The running track with the fixed installations for servicing trains is mapped, in this scenario, in both part-OPs of real operational point: |
|
as (real) running track, in (real) part-OP “Vienna” and
as (virtual) siding in (virtual) part-OP “Vienna train technical services”
|
1.1.1.3.2.2 ETCS Baseline |
Need to include “Baseline 3 Maintenance release 1” and “Baseline 3 release 2” . Also, the reference has to be changed to the corresponding table in the new CCS TSI (Regulation 2016/919): CCS TSI: Tables A2.1, A2.2 and A2.3 of Annex A of Regulation (EU) 2016/919 |
|
|
1.1.1.3.3.2 Advised number of active GSM-R mobiles (EDOR) on board for ETCS |
If ETCS B3 R2 is selected, then automatically , this value is 2 |
|
|
location point |
The Polish NRE asks us to allow negative values for the railway location of a location point |
|
|
Format use of decimals |
|
|
|
|
|
|
|
Table 9: list of admendment to Draft Guide Version 1.4 26/03/2019 |
||
|
Paragraph/Parameter/Table /Date |
Description |
according |
|
|
|
|
|
|
In the review process of the AG, I have some comments: Modified: Title: Existence of trackside hot axle box detector (HABD) definition: Existence of trackside HABD in “Can be repeated” section corrected : N ending - in my validation process I have “Applicable ‘Y’ when in parameter 1.1.1.2.4.2.1 selected option is ‘Y’.”, but I don’t find it in the AG. Do I keep this constraint or not? The correct condition is : “Applicable ‘Y’ when in parameter 1.1.1.2.4.1.1 selected option is ‘Y’.”, Yes the Agency will “set up and manage in a technical document the set of checks to demonstrate the technical compatibility of an on-board subsystem with the trackside subsystem”. The lists of possible answers is not currently known needed - data presentation list values needed |
|
Parameter 1.1.1.1.2.4.2 – is the naming “Compliance of structures with the (HSLM)” correct? NO (the naming I had was “Compliance of structures with the High Speed Load Model (HSLM) dynamic load model”) corrected in the guide
Parameter 1.1.1.1..6.4 - Document with the conditions for the use of eddy current brakes there are 2 points in the index corrected
Parameter 1.1.1.1..6.5 - Document with the conditions for the use of magnetic brakes
there are 2 point in the index corrected
Can be repeated - N? Y instead of N
Parameter 1.1.1.1.7.4 – the correct name of the parameter is “Existence of trackside (HABD)” or ”Existence of trackside hot axle box detector (HABD)”?
Parameter 1.1.1.2.2.4 – Permission for regenerative braking - there are 2 values
Parameter 1.1.1.2.4.3 – Distance between signboard and phase separation
Parameter 1.1.1.3.2.9 - no list of values
Parameter 1.1.1.3.3.9 - no list of values
Parameter 1.1.1.3.3.10 - no list of values
Parameter 1.1.1.3.6.1 - Other radio systems installed (Radio Legacy Systems) - the data presentation list should be:
UIC Radio Chapter 1-4
UIC Radio Chapter 1-4+6
UIC Radio Chapter 1- 4 + 6 (Irish system)
UIC Radio Chapter 1-4+6+7
BR 1845
BR 1609
FS ETACS and GSM
UIC Radio Chapter 1-4 (TTT radio system installed at Cascais line)
TTT radio system CP_N
PKP radio system
VR trainr
TRS — The Czech Railways radio system
LDZ radio system
CH — Greek Railways radio system
UIC Radio Chapter Bulgaria
The Estonian radio system
The Lithuanian radio system Corrected thanks
Parameter 1.1.1.3.7.1.2 - Type of track circuits to which specific checks are
|
|
The list is not still defined |
|
|
Parameters1.1.1.3.2.1 to 1.1.1.3.2.10 |
This is considered in the CCS TSI Chapter 6.4, and such deviations should be described using by the template provided by the Agency and that will be included in the CCS TSI application guide. (Website link). Examples are provided at the end of the document. If more details are needed Hans Bierlien can provide. board necessary for line access” should only be necessary for ETCS level 3, according to the Application guide it is only applicable for ETCS level 1. On the other hand there might me use-cases where it is useful to allow timed intervals, eg. at night no tic is necessary, but during the day it is. Agree. It should only by requested for Level 3 applicable for all ETCS levels and not only for level 1 Agree. It should be for all levels Agree. It should be for all levels All the modifications are copied in comments linked to the description of the parameters |
|
|
29/03/2019 |
This may be better as 1.1.1.3.7.11.1 CTD_ MinAxleLoadByVehicleCat / Minimum permitted axle load per category of Vehicle instead of 1.1.1.3.7.11.1 CTD_MinAxleLoadVehicleCat / Minimum permitted axle load per category of Vehicle 1.1.1.1.7.9 IHS_HABDDirecton/Direction of measurement of trackside HABD becomes 1.1.1.1.7.9 IHS_HABDDirection/Direction of measurement of trackside HABD |
|
|
29/03/2019 |
Something is unclear to me. On the AG, the parameter 1.1.1.1.6.4 “Document with the conditions for the use of eddy current brakes” has the XML name “CTD_ECBDocRef”. Isn’t “ILR_ECBDocRef” the correct value for it, as they belong to “ILR – Track resistance to applied loads” group of parameters? The same thing for 1.1.1.1.6.5. |
|
|
29/03/2019 |
Each NRE will be responsible for the following (until 1st January 2021): Prepare the dataset (XML file) comprising the full RINF information of the Member State including validation through data quality checks. |
|
|
02/04/2019 |
The label HHH was corrected The character string was deleted in the the data format for the provision of parameters 1.1.1.1.4.3, 1.1.1.13.1.2 and 1.1.1.1.7.8 |
|
|
02/04/2019 |
The applicaibility condition of parameters to be deleted was updated to allow to go providing them or not during the transitional period |
|
We are not sure what a restrictions meant in “1.1.1.3.2.6 Existence of operating restrictions or conditions“ would look like. Can you clarify this by providing an example?
According to our ETCS experts “1.1.1.3.2.8 Train integrity confirmation from on-
According to our ETCS experts “1.1.1.3.2.9 ETCS system compatibility” should be
The same applies for “1.1.1.3.2.10 ETCS M_version” this should be applicable for all ETCS levels instead for only level 1
NREs and Agency responsabilities Communication between RINF application and NREs
Submit the RINF dataset to the central database at ERA.
Follow-up with ERA relating to any issues on failing validation or upload.
Define the list of domestic border points, keep it updated and forward it to the Agency
Manage the data on domestic border points ERA will be responsible for the following:
Provide relevant documentation relating to maintenance and evolution of RINF.
Manage the list of MS border points
Manage reference list of domestic border points to be used in the validation process
|
02/04/2019 |
The value “nono” was added as a possible answer in the list of parameter 1.1.1..3.5.3 |
|
|
02/04/2019 |
The applicability status of parameters that are new and needed for route compatibility check was adapted in order to allow not to provide the xml line until thes parameters become mandatory to be provided in January 2020 |
|
|
04/04/2019 |
Review of the sope, and purpose of the RINF (2.2.1 to 2.2.3) |
|
|
16/04/2019 |
the list of border points: Deletion of “EU00068”, update of EU00073 |
|
|
26/04/2019 |
Update of principles according which Ops are defined (link with PLCs) |
|
|
|
users: NRE , IMs, Public users, RRU |
|
|
04/06/2019 |
Description of the process according which a NRE/IM will use the new Document management functionality |
|
|
14/06/2019 |
Cleaning of references to HS or CR TSIs Cleaning/udate of the table 2 |
|
|
21/06/2019 |
Modification of coordinates of BP EU00028 to EU00035 on request AT NRE (mail 21/05/2019), EU00028 and EU00035 stay “open”. Modification of coordinates from EU00060 to EU00063 (with Czech Republic, of EU00103 to EU00108 (with Hungaria), of EU00109 to EU00113 (with Slovakia) |
|
|
21/06/2019 |
Modifications on parameter’s description are identified by a comment |
|
|
24/06/2019 |
Modification of BP EU00111 to EU00113 on request of AT NRE (mail 24/06/2019) |
|
|
Table 10: list of amendments to Draft Guide Version 1.4.3 July 2019 Main modification to the previous version 1.4.3 are highlighted in grey |
||
|
Paragraph/Parameter/Table |
Description |
according |
|
All guide |
Cleaning, modifying RINF Decision by RINF regulation and update of corresponding paragraphs if relevant |
|
|
2.5 Parameter groups hierarchy, P32 |
The xml label is “AreaOfImpl” instead of “Areaofuse” for parameter1.1.1.3.3.3.3 /Area of implementation of GPRS |
|
|
1.1.1.1.2.4.1 / National classification for load capability / SOL Track Parameter IPP_NCLoadCap |
Explanations were added |
|
|
1.1.1.1.2.4.3 /Railway location of structures requiring specific checks/ SOL Track Parameter IPP_StructureCheckLoc |
Explanations were added |
|
|
1.1.1.1.7.10 / Steady red lights required/SOL Track Parameter/ IHS_RedLights |
Explanations (extracts of the regulation (EU) 2019/773) were added |
|
|
1.1.1.1.7.11 / Belonging to a quieter route / SOL Track Parameter IHS_QuietRoute |
Explanations (extracts of Article 5b of Regulation (EU) 1304/2014 ) were added |
|
|
1.1.1.2.2.1.2.1 / Energy supply system TSI compliant /SOL Track Parameter ECS_TSIVoltFreq |
Explanations were added |
|
|
1.1.1.4.1 /Existence of rules and restrictions of a strictly local nature /SOL Track Parameter RUL_LocalRulesOrRestrictio ns and 1.1.1.4.2 / Documents regarding the rules or restrictions of a strictly local nature available by the IM |
Explanations were added |
|
|
1.1.1.3.7.17 / Maximum sanding output Maximum amount of sand / SOL Track Parameter TD_MaxSandOutput |
Deletion of the applicability condition related to parameter 1.1.1.3.7.18 |
|
|
1.2.1.0.3.4 / Gauging / SOL Track Parameter /LL_Gauging |
IRL1 was twice in the list of possible answers, one value was deleted |
|
|
1.2.2.0.6.1 / Maximum current at standstill per pantograph / ECS_MaxStandstillCurrent |
Applicability conditions are updated |
|
|
1.2.3.1 /Existence of rules and restrictions of a strictly local nature / RUL_LocalRulesOrRestrictio ns |
Explanations were added |
|
|
2.6 Relations between Parameters |
P 35, 1st paragraph was updated |
|
|
5.1 List of parameters: table 5 ( p 48) |
Introduction of a disclaimer for NRES regarding the limits of the backward compatibility of the validation process : Most of NREs have already provided values for parameter 1.1.1.3.7.19 / TSI Compliance of rules on sand characteristics / SOL Track Parameter CTD_TSISandCharacteristics. This parameter is only applicable if the nominal track gauge corresponds to 1520 mm. CCS TSI: 3.1.4.2 of Annex A, index 77 that is the document that describes the TSI conditions of compliance indicates an open point for 1435 mm gauge. Any value indicating TSI compliance is wrong. The applicability of the parameter for other values than “1520” should be “not applicable”. |
|
|
3.3 Main principles |
The article was adapted to the July 2019 situation |
|
|
5.2 Lists of Borders points and of Domestic Border points |
Introduction of Table 7: List of domestic border points that stays currently empty, but for further RINF developments |
|
|
- 1.1.1.3.2.9 (ETCS system compatibility) : 1.1.1.3.3.9 (Radio system compatibility voice) - 1.1.1.3.3.10 (Radio system compatibility data) Where to find the list of values? When will it be available? |
Explanations added: The different values to be defined inside each network need to be submitted by each IM with the support of their suppliers to the Agency. (CCS TSI 6.1.2.4 and 6.1.2.5 – Regulation (EU) 2019/776). The Agency will then compile them in a Technical Document, give them an identifier, and after, these identifiers will be available for selection in RINF and ERA TV. Therefore, these values will not be available until the IM has communicated the checks to the Agency. There is information about the ESC/RSC and the submission to the Agency in the ERA webpage (Link). More information will be included in the CCS TSI application guide. The deadline set in the CCS TSI for IMs to complete this process is 16 January 2020. |
|
|
Parameters : SOLTunnelStart, SOLTunnelEnd, OPGeographicLocation |
Correction of an error: [Latitude (NN.NNNNNNN) + Longitude(±NN.NNNNNNN) instead of [Latitude (NN.NNNNNNN) + Longitude(±NN.NNNN) + km(±NNNN.NNNN)] |
|
|
Parameter 1.2.0.0.0.2 / Unique OP ID / UniqueOPID |
In order to ensure the continuity of the network, the validation process of the file imported by NRES will check that the Unique OP ID belongs to the table 6 –list of border points when the type of the OP is declared as “border point”. |
|
|
Table 11: list of amendments to Draft Guide Version 1.5 After September 2019 Main modification to the previous version 1.4.3 are highlighted in grey |
||
|
Paragraph/Parameter/Table |
Description |
according |
|
1.1.1.1.6.4 |
The XML name is SOL Track Parameter ILR_ECBDocRef. |
|
|
1.1.1.1.6.5 |
The XML name is SOL Track Parameter ILR_MBDocRef. |
|
|
3.4 RINF deliverables |
Title of the paragraph and versions of documents updated |
|
|
Table 12: list of amendments to Draft Guide Version 1.5.2.1. After February 2020 Main modification to the previous version 1.5 are highlighted in red and track change. General overhaul of the Application Guide |
||
|
Paragraph/Parameter/Table |
Description |
according |
|
1.1.1.1.6.4 |
The XML name is SOL Track Parameter ILR_ECBDocRef. |
|
|
1.1.1.1.6.5 |
The XML name is SOL Track Parameter ILR_MBDocRef. |
|
|
3.4 RINF deliverables |
Title of the paragraph and versions of documents updated |
|
|
Table 13: list of amendments to Draft Guide Version 1.5.2.2. After March 2020 Main modification to the previous version 1.5.2.1 are highlighted in track change |
||
|
Paragraph/Parameter/Table |
Description |
according |
|
1.1.1.1.3.1.1 |
New values added upon a request of France |
|
|
1.2.1.0.3.4 |
New values added upon a request of France |
|
|
1.1.1.3.2.9 |
New values added and repeatability is allowed again |
|
|
1.1.1.3.3.9 |
New values added and repeatability is allowed again |
|
|
1.1.1.3.3.10 |
New values added and repeatability is allowed again |
|
|
1.1.1.3.3.8 |
Explanation extended |
|
|
1.2.2.0.6.1 |
Added: “Not applicable” firstly when the siding is not electrified in DC and reference corrected |
|
|
1.1.1.1.3.4 |
Applicability has been changed |
|
|
1.1.1.1.3.5 |
Applicability has been changed |
|
|
1.1.1.2.2.3 |
Reference corrected |
|
|
Border Location points have been updated. Deleted parameters have been removed. LookUP values have been added. |
||
|
Table 14: list of amendments to Draft Guide Version 1.5.2.3. After June 2020 Main modification to the previous version 1.5.2.2 |
||
|
Paragraph/Parameter/Table |
Description |
according |
|
1.1.1.1.3.1.1 |
Applicability aligned with the RINF Regulation New values added |
|
|
1.1.1.1.7.5. |
Definition changed |
|
|
1.1.1.3.2.9 |
New values added |
|
|
1.1.1.3.3.7 |
Applicability changed |
|
|
1.1.1.3.3.9 |
Values removed |
|
|
1.1.1.3.3.10 |
Values removed |
|
|
1.1.1.3.4.1 |
Title, Definition and Reference modified |
|
|
1.1.1.3.6.1 |
New values added |
|
|
1.1.1.3.7.1.1 |
Definition changed |
|
|
1.1.1.3.7.1.2 |
XML name and Definition changed |
|
|
1.1.1.3.7.1.3 |
Definition changed |
|
|
1.1.1.3.7.2.1 |
Applicability changed |
|
|
1.1.1.3.7.11.1 |
Data presentation changed |
|
|
1.2.1.0.3.4 |
New values added and Reference modified |
|
|
1.2.1.0.3.5 |
References deleted |
|
|
1.2.2.0.3.1 |
Applicability changed |
|
|
1.2.2.0.3.2 |
Applicability changed |
|
|
1.2.2.0.3.3 |
Applicability changed |
|
|
Border Location points have been updated. |
||
|
Table 15: list of amendments to Draft Guide Version 1.5.2.4 After October 2020 Main modification to the previous version 1.5.2.3 |
||
|
Paragraph/Parameter/Table |
Description |
according |
|
1.1.1.3.2.1 |
Explanation of data presentation: clarification added |
|
|
1.1.1.3.2.9 |
New values added (BE, DK, IT, PL) |
|
|
1.1.1.3.3.2 |
Data presentation: updated to include the Value “0” (introduced in May 2019) as allowed values |
|
|
1.1.1.3.3.7 |
Explainations: sentence added |
|
|
1.1.1.3.3.9 |
New values added (AT, BE, ES, PL) |
|
|
1.1.1.3.3.10 |
New values added (AT, ES) |
|
|
1.1.1.3.6.1 |
New value added |
|
|
1.1.1.1.2.3 |
Data presentation: updated to include existing values |
|
|
1.2.1.0.2.3 |
Data presentation: updated to include existing values |
|
|
1.1.1.1.3.4 |
Data presentation: updated to include existing values |
|
|
1.1.1.1.3.5 |
Data presentation: updated to include existing values |
|
|
1.1.1.3.4.1 |
Title, Definition, Reference changed |
|
|
1.1.1.3.7.1.1 |
Definition changed |
|
|
1.1.1.3.7.1.2 |
XML Name, Definition changed |
|
|
1.1.1.3.7.1.3 |
Definition changed |
|
|
1.1.1.3.3.1 |
XML Name, Definition changed Editorial error corrected on the cells of the table |
|
|
Page 32 |
Editorial error corrected |
|
|
|
Border Location points have been updated. |
|
|
Table 16: list of amendments to Draft Guide Version 1.5.2.5 After March 2021 Main modification to the previous version 1.5.2.4 |
||
|
Paragraph/Parameter/Table |
Description |
according |
|
1.1.1.1.3.4 |
New value added |
|
|
1.1.1.1.3.5 |
New value added |
|
|
1.1.1.3.2.9 |
New value added |
|
|
1.1.1.3.7.1.2 |
Data presentation: updated to include existing values and change in one value |
|
|
1.1.1.1.3.1.1 |
New values added (ES) |
|
|
Table 17: list of amendments to Draft Guide Version 1.5.2.6 After June 2021 Main modification to the previous version 1.5.2.5 |
||
|
Paragraph/Parameter/Table |
Description |
according |
|
1.1.1.3.2.9 |
Values renamed (FR, IT) New values added (FR, IT, PL, CZ, RO, DE) |
|
|
1.1.1.3.3.9 |
New values added (ES, RO) |
|
|
1.1.1.3.3.10 |
New values added (ES, PL) |
|
|
1.2.1.0.3.4 |
XML Name corrected New values added (ES) |
|
|
1.1.1.3.3.3 |
Value “Network selection automatic” reinserted |
CER-EIM request |
|
Page 2, Table 1 |
Dates added Versions of the AG added Row deleted |
|
|
Page 190 |
Border Location point EU00009 has been updated. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Table 18: list of amendments to Draft Guide Version 1.6.0 After October 2021 Main modification to the previous version 1.5.2.6 |
||
|
Paragraph/Parameter/Table |
Description |
according |
|
Table 9, page 208 |
Editorial corrections (typos) |
BG |
|
Page 32 |
Editorial correction (typo to XML name of the parameter 1.1.1.3.7.1.2) |
|
|
Page 187 & 194 |
Border Location points EU00007, EU00008 and EU00102 updated. |
DE, BE, LU |
|
1.1.1.1.7.8 |
Editorial correction in “General explanations” (phrase deleted) |
|
|
1.1.1.1.3.1.1 |
The row “Mandatory” deleted (typo) |
BG |
|
1.1.1.3.3.9 |
Value deleted (PL), values added (DE, LU) |
|
|
1.1.1.1.2.1.2 |
References: Inaccessible link deleted; additional reference added |
|
|
1.1.1.3.7.1.3 |
Explanation on repeatability: missing phrase added |
|
|
1.1.1.3.7.1.4 |
Explanation on repeatability: missing phrase added |
|
|
1.1.1.2.4.1.2 |
Repeatability granted; Data presentation modified |
CER-EIM |
|
1.1.1.2.4.2.2 |
Repeatability granted; Data presentation modified |
CER-EIM |
|
1.1.1.3.6.1 |
Values deleted (SK) |
|
|
1.1.1.3.2.9 |
Value renamed, values added (IT, NO) |
|
|
1.1.1.3.3.10 |
Values added and renamed (ES) |
|
|
1.1.1.3.7.1.2 |
Values added (LU) |
LU |
|
1.1.1.4 |
XML name added (typo correction) |
BG |
|
1.2.3 |
XML name added (typo correction) |
BG |
|
|
|
|
|
|
|
|
|
Table 19: list of amendments to Draft Guide Version 1.6.1 After June 2022 Main modification to the previous version 1.6.0 |
||
|
Paragraph/Parameter/Table |
Description |
according |
|
1.1.1.1.3.1.1 |
Values added (CH, ES) |
CH, ES |
|
1.2.1.0.3.4 |
Values added (CH) |
CH |
|
1.1.1.3.2.9 |
Values added (CH) Values deleted (IT) |
|
|
1.1.1.3.3.9 |
Values added (CH) |
|
|
1.1.1.3.3.10 |
Values added (CH), Typo correction (ES) |
|
|
1.1.1.1.2.8 |
References correction (ENE TSI reference) |
|
|
1.1.1.1.8.3 |
Typo correction (10 m corrected to 10 cm) |
BG |
|
1.1.1.1.8.4 |
Typo correction (10 m corrected to 10 cm) |
BG |
|
1.1.1.3.7.1.2 |
Typo correction in LU values Values added (DE) |
LU, DE |
|
1.1.1.2.4.1.2 |
Data presentation and Explanation on data presentation modified |
CER - EIM |
|
1.1.1.1.3.4 |
Values added (SE, FR) |
SE, FR |
|
1.1.1.1.3.5 |
Values added (SE, FR) |
SE, FR |
|
Table 6 |
National Border Points added (EU00240 – EU00248) |
RO |
|
Table 6 |
National Border Points added (EU00018 – EU00020, EU00022 – EU0025, EU00249) |
DE & CH |
|
Table 6 |
National Border Point corrected (EU00132) |
FR |
|
|
|
|